On Mon, Dec 2, 2013 at 5:56 PM, Brian Smith <[email protected]> wrote: > 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.
Besides the replies on the list, I did get some replies off-list about this, where the CA seems to be wanting to do the straightforward way, but where compatibility concerns prompt CAs to try to back-date certs. Four thoughts: 1. I think it is 100% fine to define this as a problematic practice in our CA program strongly encourage CAs not to do it, and refuse to tolerate backdating that is done to get around our policies. 2. It still seems reasonable, for lack of any better alternative, to use the notBefore date as the best approximation of the creation/issuance/start-of-trust date, when implementing things like bug 942515. 3. It still isn't clear that, in the cases where backdating may be necessary for backward compatibility, that the certificate in question needs to be also valid for three years into the future. So, for example, we may still be able to implement checks for maximum certificate lifetime of 3 or 5 years or whatever is ultimately decided. 4. This is more evidence that mandatory CT is a good idea, because CT provides a fairly tamperproof mechanism for determining certificate issuance (or, rather, the start of the period in which the browser will trust the certificate). Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
