I would very much like to see the implementing regulations that they think causes them to need a new root rekey every year. A new CA issued by a root, sure... but a new root? That's outlandish and a substantial burden on the browser vendors.
I agree with the cross-certification aspect of Nelson's suggestion. If it's to enable TLS client authentication (and not S/MIME), there's absolutely no reason for the client to have this, since the client's PKCS#12 file will include the issuing root anyway. If it is for S/MIME, email-bit is appropriate on the client side, and the root should be present. But... expecting browser vendors to update their certificate lists every year for a single organization would mean that the browser vendors would have to expect to update the certificate list every year for ALL organizations, and would also violate the archival principle (that signatures of archived documents can be verified via the presence of a timestamp from a reputable timestamping authority and a trust anchor which still needs to be available). Until the regulations are produced, I am STRONGLY AGAINST these roots' inclusion. Even after the regulations are produced, I'm still very likely going to be against it, though I am not stating absolutely "no" at this time. (They may actually have a reason that I'll accept. I doubt it, but I'll hold out hope... if for no other reason than to point and laugh at the German government when they express a completely unfounded fear.) If I were able to commit Mozilla to any future action, what I'd do: Refuse their request and inform them to tell their regulatory agency to get in touch with Mozilla and other browser vendors to understand why it's an unacceptable burden. Those regulatory agencies need to get input on "best current practices", and help to figure out how to rewrite the regulations so that they don't impose such a burden on the browsers. -Kyle H On Tue, Dec 16, 2008 at 10:54 PM, Nelson B Bolyard <nel...@bolyard.me> wrote: > Eddy Nigg wrote, On 2008-12-16 18:20: >> On 12/17/2008 03:42 AM, Nelson B Bolyard: >>> Do the new certs for S-TRUST have the same key, or do they have >>> different keys? If they have different keys, do they also have different >>> subject names? >>> Do they have different Subject Key ID (SKID) extension values? >>> Do the certs they issue have Authority Key ID (AKID) extensions? >> >> Nelson, see this attachment from Kathleen: >> https://bugzilla.mozilla.org/attachment.cgi?id=337729 scroll to page two >> and come to your own conclusions. > > One of the reasons I asked the question is that MS Word files present a > problem for me. > > But I did dig up the URLs for the 4 CA certs, and examined those certs. > Each of them has a separate subject name, public key, subject key ID, > authority key ID, and of course validity period. > > To be honest, I think this is a burden that Mozilla ought not to bear. > Mozilla should not put itself into a position of needing to add a new > root CA cert for this CA every year, and then keep them for a long time > thereafter. > > Further, if (as the bug suggests) the REAL PRIMARY purpose of this CA > is to provide German citizens with SSL client certificates, and it is > not used to issue SSL server certs, then it is (or should be) unnecessary > for their browsers to have this CA cert AT ALL. For SSL client auth > purposes, it's quite sufficient for the browser to just have the user's > cert and private key and no CA cert at all. The server sends down a > message saying "if you have a cert issued by this CA, send it". The > browser examines the certs it possesses to find ones that have the > desired string in the issuer name, and for which the browser has the > private key. Having the CA cert is unnecessary. > > While some German law or regulation may require them to issue new roots > annually, I doubt that it prevents them from also issuing intermediate > CA certs with the same subject name, key, subject key ID, etc, but issued > by some single common root that changes infrequently (these are so-called > cross signed CA certs). With such a scheme, that root that issues the > cross signed certs can be the one to get put into Mozilla with email trust. > > So, My advice is: just say no. Don't take on the burden of adding a > new root CA cert every year when there is no good need. Please consider > this an objection to including those roots in the root CA list. > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
