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.
Perhaps I was thinking you were being a little more specific about CAcert then in general which you've now made clear, and I appologise for any misunderstanding this may have caused...
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.
This is more to do with the fact of us unsure of what we need documented, and the fact none of us have ever undertaken anything of this nature in the past, so it's all a learning experience for us.
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.
It's tagged on every single certificate issued, as well as the root certificate itself, in the last 18 months have only been asked for the URL once... Also we are planning to change to another root certificate which I think I included you on, this is for a number of reasons, one of which is to include the OCSP url which we are still playing with to get working... Also with the OCSP setup, I plan to distribute these setups (only CRLs so privacy isn't an issue) across the globe, that way even if we get DoS'ed revoked certificates will still be accessable...
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 was under the impression, that mozilla (the browser) was like MS IE in that it automatically checked based on CRL urls in certificates...
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.
I'd consider distributed OCSP responders a better option again :)
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.
the CRL is accessable via both SSL and non-SSL, and I'll be placing a link to it on the website.
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.
Thanks for the suggestion will look into this today when I get a chance to...
3. NEVER reuse a serial number that you've previously put into a cert you've issued, ESPECIALLY not for your root CA cert.
OpenSSL issues the serial numbers, and as far as I know, never issues multiples with the same serial number.
Now, tell us what other good practices you're hiding. :)
Some of note, due to the nature of automated certificate issuing, we do not allow people to have additional information on server certificates, this include company names, locations etc etc etc, the fields must be blank or duplicate the common name, while this may have upset some people it was felt that anyone could go register ibmcorp.com and try and impersonate the real IBM corp.
Also as stated in the email, we're planning to move to a root/sub-root system, with the root certificate stored securely offline, in the begining we didn't have the luxury of being able to do this as it's not possible to install more then one certificate at a time, and if a system isn't useable it won't be used, or of much use to people.
We try to follow best practices where possible, and our site is basically a living set of documents, with it being updated/modified/changed to suit comply with suggestions that make our service more secure, or benefical to our users.
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
