Rob Stradling:
Sorry Rob, yes I missed that one. But why doing that? Why not replace
with something better and remove the "offending" root? Perhaps I'm not
objective enough because we actually replaced a small key with a bigger
one. What's the logic for having a pile of roots which expire in 2010?

I didn't say "expire in 2010".

You said valid-for-not-too-far-beyond-2010 :-) I shortened that a little bit for clarity...

I think the key issue is that we don't want users of Mozilla software to be
relying on 1024-bit RSA Root Keys too far beyond 2010.

Correct.

If we were to remove any 1024-bit RSA Root Certificates from Mozilla today, it
would be damaging to the CAs (who rely on the good browser ubiquity provided
by these Roots).

Also correct.

But, if we instead wait until, say, 2013 to remove those Root Certificates
from NSS, some users would still be relying on those 1024-bit Root Keys until
nearer 2020 ('cos some users are *very* slow to upgrade their browsers).

Update rates are apparently not so bad, but supposed CAs would replace their keys with new and bigger ones, having a target date, when the old roots will be removed, they would make sure that subscribers are using certificates issued by a new root.

I believe that my proposal solves both problems.  The CAs' browser ubiquity
would not be damaged until such time that Mozilla decides the 1024-bit Keys
should be no longer be relied on.

Well, I think you are introducing an extra step here. Supposed that CAs indeed would agree to re-issue their current 1024 and smaller keys with a expiration date at some time around 2010, those CAs will most likely also want to have a new root with a bigger key size ready from which they'll want to issue certificates. Because the old root wouldn't be valid anymore in 2010, they really would be at a disadvantage because they won't have enough time to transition to a newer one.

Now, in practical terms such a process and transition takes about three years from the moment the new root is created, submitted for inclusion, starting to issue from the new root and make the old root obsolete. One must take into account at least a one year transition period for the EE certs which are still valid (there are some rumors that some CAs issue certs with a validity of 10 years, so they would have to get new certs anyway during that time ;-) ) and CRLs still must be issued from that root until the lasts certificate expires or is revoked.

With your proposal, CAs would have first to change their 1024 bit keys to an earlier expiration date, then obviously request to add a new root anyway. I wouldn't want to be in the situation to have a root with validity to only 2010 (or valid-for-not-too-far-beyond) without a acceptable replacement and time to transition.

And in the future, Mozilla users (even
with...at that point in time...fairly out-of-date software) would be
prevented from relying on 1024-bit RSA Root Keys as soon as the date decided
by Mozilla arrives.

Keep in mind that the ones which usually don't update their browser will also miss the changed 1024 bit keys with the shorter validity, hence I think the gain would be rather minimal. Therefore I think the plan suggested from Paul more realistic in every respect and 2012, maybe 2013 sounds to me doable and still within the time frame of such keys not being a risk yet.


Regards
Signer:         Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:         [EMAIL PROTECTED] <xmpp:[EMAIL PROTECTED]>
Blog:   Join the Revolution! <http://blog.startcom.org>
Phone:  +1.213.341.0390



_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to