CT Days 2020

[Devon O'Brien]

Hello ct-policy,

I'm excited to announce CT Days 2020 will be held on September 8-9 in two half-day sessions from 0900 - 1300 PDT. While we'd initially hoped for an in-person event, ongoing travel restrictions necessitate we host this event virtually.

If you are planning on attending, please fill out this registration link so we can get an accurate headcount. A final agenda and video conference information will be sent to registered attendees the week before the event.

I look forward to seeing many of you in September!

-Devon

[Clint]

Hello all,

In preparation for CT Days 2020 next week, I wanted to provide a preview of some of the changes Apple is currently planning to make to its CT Policy. We look forward to discussing further!

1. Require log operator diversity in SCTs

1. There is an inherent risk to allowing all SCTs to originate from a single Log Operator. Adjusting the policy to require including SCTs from a minimally diverse set of Log Operators will partially address the risk.

2. This change would affect certificates issued on or after April 1, 2021 only.

2. Require an additional SCT for >6 month cert lifetimes 

1. As we move to an ecosystem where the maximum certificate lifetime is a little over a year, continuing to have additional SCTs for certs on the longer end of that spectrum will help ensure the certs most at risk within the current TLS landscape also have slightly higher levels of protection against log disruption.

2. This change would affect certificates issued on or after April 1, 2021 only.

3. Allow CT Log operators to reject non-TLS certificates

• Certificate transparency is largely currently focused on the WebPKI and TLS certificates. In order to ensure log operators can preserve their services for that core use-case, log operators should be afforded the flexibility of determining whether their logs accept non-TLS certificates. The Apple Root Program should be notified at least one month prior to such a change going into affect.

4. Use more precise units in representing the policy’s technical enforcement

1. In order to ensure participants in the CT ecosystem reach the same conclusions when calculating the expected number of SCTs for a given certificate, the policy should be updated to be more precise by using days instead of months and providing a strict definition of “day”.

2. This change would affect certificates issued on or after April 1, 2021 only.

Please see an example draft CT Policy which incorporates these changes below:

/--BEGIN PROPOSED POLICY--/

Policy Requirements

Apple's policy requires at least two Signed Certificate Timestamps (SCT) issued from a CT log - once-approved* or currently approved at the time of check - and either:

• At least two SCTs from currently approved CT logs with one SCT presented via TLS extension or OCSP Stapling; or

• At least one embedded SCT from a currently approved log and at least the number of SCTs from once or currently approved logs, based on validity period as detailed in the table below.

For certificates with a notBefore greater than April 1, 2021, the number of embedded SCTs based on certificate lifetime:

   

Certificate lifetime	Minimum total # of SCTs	Maximum # of SCTs per Log Operator which count towards the SCT requirement
180 days or less	2	1
181 to 825 days	3	2
826 to 1187 days	4	N/A

Notes:

• To be considered "once-approved", the timestamp in the SCT must have been issued from a CT log that was in the approved CT log list at the time of the SCT issuance.

• A certificate's validity period (or lifetime) is defined in line with RFC 5280, Section 4.1.2.5, as "the period of time from notBefore through notAfter, inclusive."

• Validity period is measured with a day being equal to 86,400 seconds. Any time greater than this indicates an additional day of validity.

• Log operators MAY reject leaf certificates which don’t contain the serverAuth EKU.

/--END PROPOSED POLICY--/

Thanks!

-Clint

[Douglas Beattie]

Hi Clint,

Will you be providing some background about why you are recommending increasing the number of SCTs from 2 to 3  for 1-year (181-398 days) certificates?  Is there security risk driving this that we didn't take into account when the initial policy was created?

Doug

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/88339e3a-95d6-4776-9a50-becdfec9ebd1o%40chromium.org.

[Devon O'Brien]

While I obviously don't speak for Clint (or Apple, for that matter!), there are a few significant changes in the CT ecosystem since the original SCT numbers were put into policy. I expect there will be plenty of room for robust conversation during the 'Quantity & Diversity of SCTs' session on Tuesday.

1. CT Logs went from ~1 per organization to many (and not just due to sharding), including CAs who also operate multiple CT Logs. This means that today, Apple's CT Policy can readily be satisfied by a single organization issuing both the certificate and all SCTs included therein. I think it's important not to isolate this proposal from the accompanying change that states at most 2 of 3 SCTs for 181-825 day certs can come from the same Log Operator, since the two changes in conjunction appear to be more meaningful than either individually.

2. CT Logs have been Retired (formerly DQ'd) substantially more often than was originally envisioned, both due to compliance issues as well as intentional and voluntary exits from the CT ecosystem. Requiring more, and more distinct, SCTs for longer certificate lifetimes, where ~398 days should probably be considered "longer" now that SC31 has passed, is one way of mitigating the impact of individual organizations exiting the ecosystem with still-valid certificate/SCT tuples being relied upon by user agents.

3. Most TLS certificates today seek to comply with both Chrome's and Apple's CT Policies, so Apple often inherits a de-facto organizational separation in the form of Google and non-Google SCT requirements. We've publicly discussed Chrome's plans of removing this requirement, so it's definitely worthwhile to take a holistic re-evaluation of adjacent policies that could be impacted by this change.

What would probably be very useful to this conversation is to bring concrete examples of how increasing SCTs could impact CA issuance processes, certificate size, or some other factor that might be worth considering in light of this proposed requirement.

-Devon

To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+unsubscribe@chromium.org.

[Devon O'Brien]

Thank you to all who attended CT Days 2020 earlier this month. We have collected notes and compiled a brief summary of each session to share with folks who were unable to attend as well as provide reference materials for those who did. 

Thanks,

Devon

[Ivan Ristic]

Hi Clint,

For our planning purposes, what are your expectations regarding having the final version of your updated CT policy?

Our context is that we wish to verify all certificates we encounter according your new policy at the same time as you begin to enforce it in April 2021.

In this case as well, it would be great if we could have access to your test cases to ensure we're  implementing the right behaviour.

Thanks.

--

You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/88339e3a-95d6-4776-9a50-becdfec9ebd1o%40chromium.org.

--

Ivan