I must also point out something:
NSS (at least up until 2004 -- I don't know if this has been changed,
but the MoFo position espoused by I believe Nelson and Frank was that
it wouldn't change) doesn't rely on any of the X.509v3 certificate
fields of embedded trust anchors when figuring out whether to extend
trust. Thus, changing it won't have any practical value anyway.
(The argument was that X.509 makes a good container format for
distributing trust anchors -- the public keys -- along with display
metadata, but that the trust anchor itself could be distributed
separately from the X.509 container and thus should not be subject to
any policy statements included in that container. Which didn't make
any sense to me at the time, and still doesn't -- since that container
is signed by that key anyway, and I would expect it to adhere to the
CPS espoused by that key -- but that's how it was explained.)
-Kyle H
2008/6/5 Eddy Nigg (StartCom Ltd.) <[EMAIL PROTECTED]>:
> 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.
> Jabber: [EMAIL PROTECTED]
> Blog: Join the Revolution!
> Phone: +1.213.341.0390
>
>
>
> _______________________________________________
> 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
