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. :-)
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. See also http://stackoverflow.com/questions/9234796/does-the-expiration-status-of-an-issuers-certificate-affect-a-subjects-expirat Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
