On Friday 06 June 2008 10:07:20 Gervase Markham wrote:
> Nelson B Bolyard wrote:
> > Rob, in the past, any time that we have suggested that a CA issue a new
> > root CA cert for any reason, even if only to change something minor,
> > we've received much feedback saying that doing so represents a huge
> > challenge and investment for the CAs, necessitating modifications to
> > CPSes, triggering new audits, etc. etc. One gets the impression from
> > those replies that this is something the CAs would rather avoid at
> > (nearly) all cost.
>
> Another option would be to make a (small? :-) modification to NSS to
> allow us to store an expiry date which overrode the one in the certificate.
Good idea. That would be much less hassle (compared to my proposal) for both
the CAs and Mozilla.
Or, instead of modifying the data that NSS holds for each certificate...
Yet another alternative option would be to make a modification to NSS's
certificate path processing code, so that whenever NSS is attempting to build
a certificate chain up to a trusted Root it would check:
- the current date/time.
- the key sizes of each certificate it is considering trusting.
- a hard-coded array of: { algorithm, key_size, soft_insecure_after_date,
hard_insecure_after_date }.
Whenever a key is found whose "soft_insecure_after_date" is in the past,
NSS/Firefox/etc would warn the user, but allow them to choose to navigate to
the HTTPS site if they really want to.
Whenever a key is found whose "hard_insecure_after_date" is in the past,
NSS/Firefox/etc would warn the user and refuse to allow them to navigate to
the HTTPS site.
I think it would make sense for the "soft_insecure_after_date"s to match
NIST's recommendations, but the "hard_insecure_after_date"s would be up to
Mozilla to define.
Also, the hard-coded array could be extended to define algorithm expiry
information for not only RSA key-sizes, but also...
- Hash algorithms used in signatures (e.g. NIST specify a 2010 deadline for
SHA-1; and I think MD2/4/5 and SHA-0 should already be deemed to have passed
their "soft_insecure_after_date").
- ECC key-sizes and curves.
- Symmetric algorithms used in SSL cipher suites.
NSS could check all of these during certificate path processing and SSL/TLS
handshakes.
With this approach, Mozilla could even continue to accept new 1024-bit Root
Certificate submissions for the next few years (not that I'm advocating that,
of course!)
> Gerv
> _______________________________________________
> 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
