On Mon, May 22, 2017 at 1:41 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On Monday, May 22, 2017 at 11:50:59 AM UTC-5, Gervase Markham wrote: > > > How do the various validation routines in the field today validate a > > > scenario in which a leaf certificate's validity period exceeds a > > > validity period constraint upon the chosen trust path? Is the > > > certificate treated as trusted, but only to the extent that the > > > present time is within the most restrictive view of the validity > > > period in the chain, or is the certificate treated as invalid > > > regardless for failure to fully conform to the technical policy > > > constraints promulgated by the chain? > > > > Good question. I think the former, but Ryan Sleevi might have more info, > > because I seem to remember him discussing this scenario and its compat > > constraints recently. > > > > Either way, it's a bad idea, because the net effect is that your cert > > suddenly stops working before the end date in it, and so you are likely > > to be caught short. > > Here I would concur that it would be bad practice for precisely the reason > you indicate. I was mostly academically interested in the specifics of > that topic. I would agree that extending the certificate lifecycle to some > period beyond the max EE validity period would alleviate the need. Having > said that, I can still envision workable scenarios and value cases for such > technically constrained CA certificates even if it were deemed unacceptable > to extend their validity period. > As Gerv notes, clients behave inconsistently with respect to this. With respect to what is specified in RFC 5280, the critical requirement is that all certificates in the chain be valid at the time of evaluation. This allows, for example, the replacement of an intermediate certificate to 'extend' the lifetime of the leaf to its originally expressed value. However, some clients require that the validity periods be 'nested' appropriately - and, IIRC, at one time Mozilla NSS equally required this. So the need exists to define some upper-bound for the TCSC relative to the risk. One approach is to make an argument that the upper-bound for a certificate is bounded on the validity period of an equivalently issued leaf certificate - that is, say, 825 days. Another approach is to make an argument that since a CA can validate a domain at T=0, issue a certificate at T=0 with a validity period of 825 days, then issue a certificate at T=824 with a validity period of 825 days, the 'net' validity period of a domain validation is T=(825 days * 2) - 1 second. (Here, I'm using 825 as shorthand for the cascading dates) Another approach is to make an argument that such validations are already accounted for in the EV Guidelines, in which a certificate may be issued for 27 months, but for which the domain must be revalidated at 13 months. In this case, the TCSC might be issued for an 'extended' period (perhaps on an order of many-years), with the expectation that the CA will revoke the TCSC if the domain does not (periodically) revalidate. Each of these approaches are with their own tradeoffs in design, complexity, and risk, and argue more or less strongly for disclosure because of it. My own take is that I would prefer to see TCSCs uniquely named (e.g. through the use of dnQualifier), limited to the validity period permitted of leaf certs (since they're, effectively, "ultra" wildcards), with some robust diclosure & revocation story. I'm concerned that extending the period of time is to incentivize such certs, which introduce additional risks to the evolution of the Web PKI. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
