On 03/12/13 01:56, Brian Smith wrote:
On Mon, Dec 2, 2013 at 3:28 PM, Eddy Nigg <[email protected]> wrote:
On 12/02/2013 08:38 PM, From Brian Smith:
Why? Could you please explain what problem would be created if the renewed
certificates had a different (later) notBefore time?
certificate has been, can't have a earlier before-date than the issuer (or
at least shouldn't). But it can still correctly chain to the new one which
is usually the whole idea of such PKI acrobatics. :-)
Brian, over the years we've backdated the notBefore date on several
Intermediate certs in order to influence which of several possible
chains gets selected by various browsers. PKI acrobatics is a good
description. It completely sucks, but it's been necessary.
The most notable example of this was when IE7 launched in late 2006.
IE7 was the first browser to differentiate between EV and non-EV SSL
certs in its UI. On WinXP, once a Root cert is installed in the
CryptoAPI Trusted Root Certificate store, it's impossible to change that
Root's EV settings. Since none of the existing deployed Roots were
EV-enabled, this meant that most CAs had to embed a new Root in Windows,
EV-enabled from the start, and had to issue a backdated
cross-certificate from their older Root(s).
Without the backdating, IE7 would've picked the cross-certified chain
(up to the older, non-EV-enabled Root), and the EV UI would not have
been shown.
Here's some info on how MS CryptoAPI picks a chain:
http://blogs.technet.com/b/pki/archive/2010/05/13/certificate-path-validation-in-bridge-ca-and-cross-certification-environments.aspx
IIRC, the classic NSS chain building code uses notBefore in a similar
fashion (or at least it used to).
However...
I can't think of any reason why a CA would need to back-date an
_end-entity_ certificate. So by all means list this as a potentially
problematic practice.
Also, I can't think of any reason why a CA would need to _forward-date_
any CA cert or EE cert. I guess this is covered by Gerv's text "It
should be a reasonable reflection of the date on which the certificate
was issued", but it might be worth clarifying this by changing the
heading from "Backdating the notBefore date" to something else.
AFAICT, this is not correct, and the reason it isn't correct is
exactly to support the type of thing we're talking about here. When
validating a certificate chain at a given time T (usually the current
time), each certificate in the chain must have notBefore <= T <=
notAfter. There is no constraint in RFC 5280 defining any relation
between the notBefore and notAfter dates between certificates in the
chain.
An implementation that requires the validity period of the issuer's
certificate to subsume the validity period of the issued certificate
would be implementing a non-standard and overly-restrictive
constraint. Let's see some evidence of a web browser that does enforce
such a non-standard constraint, before we attempt to accommodate such
creatures.
IIRC, some versions of IE5 enforced this non-standard constraint.
(Obviously IE5 is no longer a concern, but perhaps its influence lives
on...)
See also
http://stackoverflow.com/questions/9234796/does-the-expiration-status-of-an-issuers-certificate-affect-a-subjects-expirat
Cheers,
Brian
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +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-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
