Andrew Ayer <a...@andrewayer.name> wrote: > The N month turnaround is only a reality if operators of TCSCs start > issuing certificates that comply with the new rules as soon as the new > rules are announced. How do you ensure that this happens? >
Imagine that the TCSCs are also required to have a short validity period, N months. Further, require that each TCSC indicate using a certificate policy (as already in the spec, or perhaps some simpler mechanism) that indicates the version of the technical requirements on certificates that that TCSC is trusted for. Then the end-entity certificates are also similarly marked. Each policy implicitly maps to a period of time for which that policy applies. At any given time, trusted CAs are only allowed to issue TCSCs with validity periods that are within the period of time specified by all policies listed in that TCSC. Let's say that this was implemented already two year ago. At that time CAs could issue SHA-1 certificates and so a TCSC could be issued for the policy which browsers understand allows TCSCs to be issued. Root programs require that all such TCSCs expire before January 1, 2016, because that's when SHA-1 issuance became disallowed. Also, browsers have code in them that make it so that certificates without that policy OID included won't be trusted for SHA-1. Now, let's say I got a TCSC for example.com in March 2015, and I want to issue SHA-1 certificates, so I ask for that allow-SHA1 policy OID to be included in my TCSC. That means my certificate will expire in January 2016, because that's the end date for the allow-SHA1 policy. And also, browsers would be coded to not recognize that policy OID after January 2016 anyway. Now, December 2015 roles around and I get another TCSC for January 2016-January 2017. But, the allow-SHA1 policy isn't allowed for that validity period, so my TCSC won't have that policy; instead it will have the only-SHA2 policy. Now, here are my choices: * Do nothing. My intermediate will expire, and all my servers' certificates will become untrusted. * Issue new SHA-1 end-entity certificates from my new only-SHA2 intermediate. But, browsers would not trust these because even if the end-entity cert contains the allow-SHA1 policy OID, my TCSC won't include it. * Issue new SHA-2 end-entity certificates from my new only-SHA2 intermediate. The important aspects with this idea are: 1. Every TCSC has to be marked with the policies that they are to be trusted for. 2. Root store policies assign a validity period to each policy. 3. Browsers must enforce the policies in code, and the code for enforcing a policy must be deployed in production before the end (or maybe the beginning) of the policy's validity period. 4. A TCSC's validity period must be within all the validity periods for each policy they are marked with; that is, a TCSC's notAfter must never be allowed to be after any deprecation deadline that would affect it. Note that for the latest root store policies, we may not know the end date of the validity period for the policy. This is where we have to choose an amount of time, e.g. 12 months, and say we're never going to deprecate anything with less than 12 months (unless there's some emergency or whatever), and so we'll allow TCSCs issued today for the current policies to be valid for up to 12 months. Also note that the existing certificate policy infrastructure used for the EV indicator could probably be used, so the code changes to certificate validation libraries would likely be small. Thoughts? Cheers, Brian -- https://briansmith.org/ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
