Here's a bit of history on that subject. A certain well-known CA had some root CA certs that expired on the eve of Y2K. As I recall, they claimed copyright (as Florian described above) and, IIRC, they had a policy of not allowing their certs to be distributed except inside releases of software that relied on their certs. They had new CA certs, but they wouldn't allow those certs to be downloaded individually (apart from other software) by end users, as I recall.
Sigh, that is _so_ brain-dead.
To avoid a repetition of that scenario, it might be advisable for MF's CA policy to require that CAs permit MF to distribute CA certs via means of MF's own choosing as a condition of inclusion in MF's root CA list.
I can certainly add a new item to the CA requirements in the policy:
5. We require that all CAs whose certificates are distributed with
our software products: ... * permit redistribution of their certificate(s) with our software
products or through other means as we may choose to do soHowever in practice what's the actual point of this? Assuming that a "certain well-known CA" continues the policy of not allowing end users to download their cert directly, are we going to yank them from the included cert list because they don't meet the requirements? I doubt it.
I don't think it's a good idea to include policy language that one is not likely to enforce should it come to that, especially for a problem that may or may not actually occur.
At the very least, MF should know in advance which CAs will similarly not permit distribution of replacement root CA certs apart from software distributions. It would also be advisable for MF to keep track of upcoming root CA expirations and plan releases for them.
I do agree that we need a plan for this. My proposal is not to revise the actual 1.0 policy to address this, but to first look at the actual situation (in terms of CA cert expiry dates and relevant CA copyright language) and see how serious this problem actually is today. At the same time we can consider ways to push out root cert list updates. (Things like the Firefox update mechanism are obvious candidates, but then we have to address the whole signed XPI issue.)
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
