On Jun 9, 2:55 pm, Michael Ströder <[EMAIL PROTECTED]> wrote:
> I really wonder what makes a host name an "unqualified hostname"?
One workable definition is a host name without a dot "." (ignoring any
trailing dots).
For example:
example.com is qualified
foo is unqualified
com is unqualified
foo.
Paul Hoffman wrote, On 2008-06-09 18:31 PDT:
> At 2:56 PM -0700 6/9/08, Nelson B Bolyard wrote:
>>> a CA that tries to save the customer by revoking the possibly-compromised
>>> domain's keys is overstepping its responsibility.
>>
>> The keys in question are not "possibly compromised". They are c
Nelson B Bolyard:
One or more well known and large CAs have already found many certs whose
public keys are in that list. There's no question that those keys are
compromised, The question is: what are the CAs' responsibility regarding
the certs with those compromised keys?
That really depen
Eddy Nigg (StartCom Ltd.) wrote, On 2008-06-09 17:19:
> Nelson B Bolyard:
>>
>> In this case, the guy held up a bag of ~96 thousand private keys and said
>> "See, here are 96 thousand private keys that I possess. Anyone can have a
>> copy of them." I can't imagine better proof of key compromise
At 2:56 PM -0700 6/9/08, Nelson B Bolyard wrote:
>Paul Hoffman wrote, On 2008-06-09 09:41:
>> At 11:22 AM +0200 6/9/08, Jean-Marc Desperrier wrote:
>
>>> Aren't the people who send their credit card number on an https
>>> connexion where the private key of the server is public knowledge
>>> alr
Nelson B Bolyard:
In this case, the guy held up a bag of ~96 thousand private keys and said
"See, here are 96 thousand private keys that I possess. Anyone can have a
copy of them." I can't imagine better proof of key compromise than that.
Oh well, I could add another few thousands to tho
Nelson B Bolyard wrote:
David Stutzman wrote, (quoting me) On 2008-06-09 04:46 PDT:
In NSS version 3.10 and later versions, pk12util has a third command
option, in addition to -i (import) and -o (export) there is -l (that's
ell, as in list). You can use it to list the contents of your PKCS
Eddy Nigg (StartCom Ltd.) wrote, On 2008-06-09 15:23:
> Nelson B Bolyard:
(quoting Paul Hoffman, quoting Jean Mark Desperrier)
Aren't the people who send their credit card number on an https
connexion where the private key of the server is public knowledge
already screwed ?
Nelson B Bolyard:
Aren't the people who send their credit card number on an https
connexion where the private key of the server is public knowledge
already screwed ?
Yes, of course. The question for this thread is: who is responsible
for each screwedness?
I beg to differ. The qu
Wan-Teh Chang wrote:
> There is a bug on certs containing unqualified host names:
> https://bugzilla.mozilla.org/show_bug.cgi?id=401317
I really wonder what makes a host name an "unqualified hostname"?
No doubt that https://www/ looks like a valid example to us humans. But
how about https://com/
David Stutzman wrote, (quoting me) On 2008-06-09 04:46 PDT:
>> In NSS version 3.10 and later versions, pk12util has a third command
>> option, in addition to -i (import) and -o (export) there is -l (that's
>> ell, as in list). You can use it to list the contents of your PKCS#12
>> file. It w
Paul Hoffman wrote, On 2008-06-09 09:41:
> At 11:22 AM +0200 6/9/08, Jean-Marc Desperrier wrote:
>> Aren't the people who send their credit card number on an https
>> connexion where the private key of the server is public knowledge
>> already screwed ?
>
> Yes, of course. The question for this
Kyle Hamilton wrote, On 2008-06-08 13:28:
> My thought is that if there's any knowledge that a CA has that a key
> has been compromised, the CA can no longer verify the binding of the
> key to the subject -- which means that the certification should not
> exist, and thus must be revoked.
On the
On Sun, Jun 8, 2008 at 6:54 PM, Nelson B Bolyard <[EMAIL PROTECTED]> wrote:
>
> I recently encountered a web site with a certificate that chained through
> two intermediate CAs to one of Mozilla's trusted roots.
>
> This cert's Subject Alt Name (SAN) extension included:
>
> - 43 wildcard domain nam
Eddy Nigg (StartCom Ltd.) wrote:
> For internal networks, internally assigned domain names should be used,
> like NETWORK = intern.domain.com
Thinking further about this whole stuff:
I consider the hostname checking to be a very important validation of
whether the browser really connects to a ho
Paul Hoffman wrote:
>
> However, given that a CA cannot know whether or not a domain has been
> compromised, a CA that tries to save the customer by revoking the
> possibly-compromised domain's keys is overstepping its responsibility.
Whether the CA is overstepping its responsibility is subjec
At 11:22 AM +0200 6/9/08, Jean-Marc Desperrier wrote:
>Paul Hoffman wrote:
>> [...]
>> Sure, but that's not the model most CAs have with their customers. I
>> would bet that if a CA sent out a message saying "we're revoking your
>> cert tomorrow, here's a new one" to all of its affected custome
Nelson B Bolyard:
The 44 DNS names don't bother me any. I'm quite willing to believe that
the issuer verified that all those domains had the same registrant.
But the 12 simple host names and the 4 routable IP addresses (each of
which appears twice) bother me.
If I go to a url such as https://1
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
la.org] On Behalf Of Nelson B Bolyard
> Sent: Sunday, June 01, 2008 4:01 PM
> To: mozilla's crypto code discussion list
> Subject: Re: Problems importing pkcs12 keystore to NSS
> In NSS version 3.10 and later
Jean-Marc Desperrier wrote:
> Michael Ströder wrote:
>> [...]
>> RFC 2818 (only INFORMATIONAL) references RFC 2459 concerning matching
>> rules which was obsoleted by RFC 3280 which was recently obsoleted by
>> RFC 5280. RFC 5280 references "Preferred name syntax" in RFC 1034.
>>
>> Glancing over t
Michael Ströder wrote:
> [...]
> RFC 2818 (only INFORMATIONAL) references RFC 2459 concerning matching
> rules which was obsoleted by RFC 3280 which was recently obsoleted by
> RFC 5280. RFC 5280 references "Preferred name syntax" in RFC 1034.
>
> Glancing over these documents I found no provision
Frank Hecker wrote:
> I agree that it would be a good thing if Entrust (or any CA, for that
> matter) used technical means (like sending email to postmaster or
> whatever) to verify domain name ownership for non-EV SSL certs, in
> addition to whatever other procedures are used.
In the past, at le
Nelson B Bolyard wrote:
> But one could imagine that we make use of them, and allow the values of
> the CKA_END_DATE to be different from (earlier than) the notAfter date
> in the related certificate.
It's good to know that this is technically possible.
But actually, I don't see this as a high pr
Paul Hoffman wrote:
> [...]
> Sure, but that's not the model most CAs have with their customers. I
> would bet that if a CA sent out a message saying "we're revoking your
> cert tomorrow, here's a new one" to all of its affected customers, fewer
> than 95% would have the new cert installed correctl
Nelson B Bolyard wrote:
>
> Likewise, if I go to https://home/ and get a "home" page for some
> enterprise, what assurances have I really been offered?
None, since your browser cannot check whether home is a fully-qualified
domain name.
> Does this bother any one else ?
Yes.
> Should Mozilla'
25 matches
Mail list logo
