Re: Debian Weak Key Problem

If the CPS doesn't define it as "compromised" in that circumstance, then the CA with that CPS has no business being trusted by me. Yet, I'm never given a choice. Not unless I go through each and every single entry in the root list and apply my own criteria to it. Better, for me, to not have to d

Re: Debian Weak Key Problem

At 7:50 PM -0700 6/9/08, Nelson B Bolyard wrote: >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

Re: Debian Weak Key Problem

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 question is:

Re: The TLS Report

Eddy Nigg (StartCom Ltd.): Frank Hecker: I tried out my own site on it, and got a C. LOL, I got a A 80 :-) Actually it doesn't honor SAN DNS extension...but it's a cute utility. Reached a A 82 as well, just need to use the CN value of the certificate.

Re: The TLS Report

Mohamad Badra CNRS - LIMOS Laboratory Eddy Nigg (StartCom Ltd.) a écrit : > Frank Hecker: >> I tried out my own site on it, and got a C. I think you deserve better than Addy if you enable EDH based ciphersuites :) > > LOL, I got a A 80 :-) Bravo, better than Microsoft:) Best regards, Badra

Re: The TLS Report

Frank Hecker: I tried out my own site on it, and got a C. LOL, I got a A 80 :-) Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: Join the Revolution! Phone: +1.213.341.0390

The TLS Report

I saw this in an O'Reilly Radar posting and am surprised no one on this group has previously mentioned it: http://tlsreport.layer8.net/ I tried out my own site on it, and got a C. Unfortunately the site doesn't include a detailed guide to how the scoring is done, but I'm guessing I got marked

Re: Debian Weak Key Problem

On Sun, Jun 8, 2008 at 5:56 PM, Paul Hoffman <[EMAIL PROTECTED]> wrote: > At 1:28 PM -0700 6/8/08, Kyle Hamilton wrote: >>How much does it cost the CA to mint a new certificate? How much >>liability does the CA assume in the case where a subject's certificate >>is used by someone other than the su

RE: Problems importing pkcs12 keystore to NSS

> -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > la.org] On Behalf Of Nelson B Bolyard > Sent: Monday, June 09, 2008 6:01 PM > To: mozilla's crypto code discussion list > Subject: Re: Problems importing pkcs12 keystore to NSS > > What tool produced those PKC

Re: Debian Weak Key Problem

Nelson B Bolyard wrote: > Agreed, and part of the discussion here is: is it acceptable to Mozilla > to continue to "trust" certs from CAs who don't revoke timely in the > presence of evidence? I hope not. Such CAs provide only "security > theater", IMO. Yupp. > Actually, I think most of them al

Re: Debian Weak Key Problem

Paul Hoffman wrote: >> The keys in question are not "possibly compromised". They are >> compromised. >> Period. > > Until we see any evidence of this in the real world, we disagree. Oh, come on. With ready-to-use tools to scan for these weak keys the evidence is there. >> A CA who informs it r

Re: Debian Weak Key Problem

Eddy Nigg (StartCom Ltd.) wrote: > I could produce millions of keys in my free time and post them to some > web site...I could tell you now that those are all compromised keys and > all CAs should now scan their subscribers keys against the ones I > posted. Should it find one, it should revoke i

Re: Certs bearing simple host names and public IP addresses OK?

[EMAIL PROTECTED] wrote: > 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). This would exclude issuing certs for a top-lev

Re: Debian Weak Key Problem

Nelson B Bolyard wrote: > It may be reasonable for a CA to assume that the subscriber has taken due > care to generate a good key pair at the time that the certificate signing > request is received, but at such time as the CA has evidence that the key > is compromised (especially public evidence),