On Thursday 05 June 2008 15:46:54 Kyle Hamilton wrote:
> 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.
Are you saying that NSS *never* checks the "notAfter" dates of its built-in
Root Certificates?
If so, does this mean that products relying on NSS will still trust built-in
Root Certificates after those Root Certificates have expired?
> (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
--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
