Duane wrote: > you are coming out in an agressive
manner simply dismissing us, on what can only be described as the 11th hour to sink us,
Duane,
I'm not trying to sink you. I'm trying to get mozilla to set an open standard by which to decide who's in.
Based on my guess about what that standard will be when it emerges, and what I've been able to figure out about your CA, I think you're closer than you think I think.
I must say this: you're REALLY underselling your own practices.
Your CA already meets more of the criteria I listed than you've let on. SO, why don't you tell us about the criteria it meets?
For example, Your CA apparently operates a working CRL, but I didn't find that mentioned ANYWHERE on your web site. I didn't find any link about revocation or CRLs on your web pages.
Your web pages should have a link to download your CRL right next to the
link to download the root CA cert itself. mozilla (the browser) will automatically download updates after that.
I found it only after I downloaded and looked at your root CA cert, and
noticed it had an extension with the URL for the CRL. I typed that CRL
into mozilla, and it downloaded the CRL, and asked me if I wanted to automatically fetch updates. So, your CRL's appear to work with mozilla. Working CRLs are WAY WAY better than no CRLs. I'd consider a CA with CRLs
_OR_ OCSP to have a passing mark on the revocation question, for example.
OCSP servers in tsunami-resistant UPS-lined caves are merely icing on the revocation cake.
So, I encourage you to be more forthcoming with info about your practices.
Here are a couple more suggestions that might help.
1. Make your CRLs available by http, as well as, or instead of https. That way, users who trust your CA for email but not for https can still access your CRLs. Also, Another vendor's PKI software considers all certs from a CA to be revoked after the "nextUpdate" field of that CA's CRL has passed. So, if a user is using your CRLs, and for some reason does not get an updated one before the "nextUpdate" date passes, he may not be able to fetch a new CRL from your https server, because his PKI software may treat your https server's cert as revoked! So it's a good idea to be able to get your CRLs without SSL. The signature on the CRL itself shold obviate SSL for that purpose anyway.
2. In your certs and CRLs, when you give an "authority key ID" extension, list the KeyID, OR the (issuer name AND serial Number), but NOT both. My advice on this: use KeyIDs only. RFC 3280 also recommends this. If you ever have to reissue your root cert, you'll be glad you didn't put issuer serial numbers into into your authkeyid extensions. Also, root CA certs need not have an "Authority Key ID" extension. See RFC 3280, page 26.
3. NEVER reuse a serial number that you've previously put into a cert you've issued, ESPECIALLY not for your root CA cert.
Now, tell us what other good practices you're hiding. :)
-- Nelson B
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
