On 03/12/13 11:29, Rob Stradling wrote: > 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.
Yes, we would need to permit this use case. > 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. I think that's a good enhancement. > Also, I can't think of any reason why a CA would need to _forward-date_ > any CA cert or EE cert. Might a CA not decide, for some reason (perhaps they are doing direct root issuance for this legacy situation, and it's a pain) to issue a 2013 cert, a 2014 cert and a 2015 cert all at the same time, and give them to the customer, knowing that they would use the first for a year, then the second, then the third? Or is there no practical reason anyone might want to do this? > 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. How is forward dating a problematic practice? Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
