Apple's Next CT Policy Update

[Clint Wilson]

Hello all,

As previously posted, Apple will be making several changes to its CT Policy in the coming months. The changes are broadly the same as previously communicated, but I wanted to confirm them for the community here. I also want to call out one substantial change, which is a shift in enforcement date from April 1, 2021 to April 21, 2021.
These changes will, in the future, also be reflected in the official article here: https://support.apple.com/HT205280

Summary of Changes

1. Require log operator diversity in SCT proofs
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. In order to ensure intercompatibility within the industry, this will not be enforced technically initially.
3. This change affects certificates issued on or after April 21, 2021 only.
2. Require an additional SCT for >180 day (~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 affects certificates issued on or after April 21, 2021 only.
3. Allow CT Log operators to reject non-TLS certificates
1. Certificate transparency is 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 45 days prior to such a change going into effect.
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 affects certificates issued on or after April 21, 2021 only.

Apple's Certificate Transparency policy

Learn how to comply with Apple's Certificate Transparency policy.

Publicly trusted Transport Layer Security (TLS) server authentication certificates must meet Apple's Certificate Transparency (CT) policy to be evaluated as trusted on Apple platforms. 

Certificates that fail to comply with this policy will result in a failed TLS connection, which can break an app’s connection to Internet services or Safari’s ability to seamlessly connect. 

Policy Requirements

Apple's policy requires at least two Signed Certificate Timestamps (SCTs) issued from a CT log - once-approved[1] or currently approved[2] 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 value greater than or equal to April 21, 2021 (2021-04-21T00:00:00Z), the Number of embedded SCTs based on certificate lifetime:

Certificate lifetime	# of SCTs from separate logs	Maximum # of SCTs per log operator which count towards the SCT requirement
180 days or less	2	1
181 to 398 days	3	2

For certificates with a notBefore value less than April 21, 2021 (2021-04-21T00:00:00Z), the Number of embedded SCTs based on certificate lifetime:

Certificate lifetime	# of SCTs from separate logs
Less than 15 months	2
15 to 27 months	3
27 to 39 months	4
More than 39 months	5

Notes

1. To be considered "once-approved", the timestamp in the SCT must have been issued from a CT log with a "Qualified" or "Usable" status at the time of the SCT issuance.
2. For CT log status definitions, please refer to Apple’s Certificate Transparency log program: https://support.apple.com/kb/HT209255
3. 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."
1. Validity period is measured with a day being equal to 86,400 seconds. Any time greater than this indicates an additional day of validity.
4. For certificates with a notBefore value equal to or greater than 2021-04-21T00:00:00Z, log operators MAY reject leaf certificates which don’t contain the serverAuth EKU.
1. Log operators MUST provide a minimum of 45 days’ advance written notice to certificate-tran...@group.apple.com of any changes to the accepted set of leaf certificates their log(s) accepts.

[Jeremy Rowley]

Hey Clint, 

Just to be clear, '

"Log operators MUST provide a minimum of 45 days’ advance written notice to certificate-tran...@group.apple.com of any changes to the accepted set of leaf certificates their log(s) accepts." is a bullet point to 4, meaning the 45 days notice is only in effect for changes about rejecting leaf certificates that don't contain the serverAuth EKU. 

Should this actually apply to all changes to log operator policy? For example, if the log changes to allow inclusion of other EKUs? I am assuming it doesn't apply to "changes to the accepted set of leaf certificates their log accepts" where the change is caused by removal or additions of new roots?

Jeremy

[Clint Wilson]

Hi Jeremy,

The addition of requiring 45 days' advance notice is to ensure awareness of log operators updating to reject non-TLS leaf certificates, but applies also in reverse if they were to later begin (re)accepting non-TLS leaf certificates.

It doesn’t apply to adding or removing roots.

Cheers!

-Clint