(Draft Ballot) Browser Alignment

[sleevi]

This is now an official ballot at cabforum#195

[dougbeattie]

I think the OCSP signing EKU should be permitted in CA certificates to permit direct signing of OCSP responses. What was the reason for adding that to the excluded list of EKUs?

[dougbeattie]

For CRL reasons you specify some (all?) Reason Codes that are not permitted:

• The CRLReason indicated MUST NOT be unspecified (0), MUST NOT be certificateHold (6), and MUST indicate the most appropriate reason for revocation of the certificate.

That does not appear to be an exhaustive list of codes that MUST NOT be used, because removeFromCRL should never be on the list (perhaps by definition it can't be in a CRL, not sure).

Instead of listing what cannot be in the CRL, should we list the values that are permitted from RFC 5280? This is the list. Are 1-5 the only ones we'd ever want to see, and 2 only for CA certificates?

    unspecified             (0),
    keyCompromise           (1),
    cACompromise            (2),
    affiliationChanged      (3),
    superseded              (4),
    cessationOfOperation    (5),
    certificateHold         (6),
         -- value 7 is not used
    removeFromCRL           (8),
    privilegeWithdrawn      (9),
    aACompromise           (10) }

[sleevi]

I think the OCSP signing EKU should be permitted in CA certificates to permit direct signing of OCSP responses. What was the reason for adding that to the excluded list of EKUs?

The EKU isn't required for signing OCSP responses directly from the issuer. (Reference: mozilla.dev.security.policy)

Instead, the digitalSignature keyUsage is used. (Reference: Microsoft Root Program, 3.A.1.D)

Delegated OCSP responders are only permitted to have a single EKU, id-kp-OCSPSigning. (Reference: Microsoft Root Program, 3.A.12)

[sleevi]

That does not appear to be an exhaustive list of codes that MUST NOT be used, because removeFromCRL should never be on the list (perhaps by definition it can't be in a CRL, not sure).

I'm not sure I follow. Are you suggesting this can't be used for an OCSP response, a CRL response, or both?

It's permitted for use in CRL, even when certificateHold is not permitted.
Reference: RFC 5280, Section 5.2.4

   CRL issuer MAY optionally list a certificate on a delta CRL with
   reason code removeFromCRL if the notAfter time specified in the
   certificate precedes the thisUpdate time specified in the delta CRL
   and the certificate was listed on the referenced base CRL or in any
   CRL issued after the base but before this delta CRL.

The BRs haven't forbidden Delta CRLs from being used, so I left it in. I think you're getting to the point of where I was going with a CRL/OCSP profile, which would clarify the expectations here, but I was thinking of that as more future work.

Instead of listing what cannot be in the CRL, should we list the values that are permitted from RFC 5280? This is the list. Are 1-5 the only ones we'd ever want to see, and 2 only for CA certificates?

For better or worse, root programs don't express prohibitions on privilegeWithdrawn or aaCompromise. 5280 doesn't include the descriptions for these reasons, but they are part of the ITU-T series. Note that 5280 intentionally allows these reasons to be expanded, which ITU-T has done (with the weakAlgorithmOrKey reason). In the case of privilegeWithdrawn, and as described by ITU-T, it's not unreasonable to use this as a revocation reason for a CDN-operated certificate (e.g. to address BygoneSSL), or with something like an HTTP Signed Exchanges or TLS Delegated Credentials certificate, as it matches the intended use.

While I'm definitely a fan of a prescriptivist approach to CRL reasons, and would like to see a ballot addressing that (and the broader profile), I was mostly only trying to capture the existing requirements here.

[BenWilson-Mozilla]

In light of the preceding bullet, I think this is confusing: "The reasonCode extension MUST NOT be present for unspecified revocations. RFC 5280 places this as a SHOULD, due to requiring an additional 12 bytes to encode the extension that is semantically equivalent to omitting it. The combination of requiring meaningful revocation reasons and wanting to ensure reasonably-sized CRLs means this value MUST NOT be present. (Section 7.2.2 (a))" Is this provision just for End Entity CRLs?

Also, this is confusing - "On 2020-09-01T00:00:00Z, the validity period for Subscriber certificates MUST be less than or equal to 398 days, and SHOULD be less than or equal to 397 days." Why is the "SHOULD" phrase there?

[clintwilson]

Also, this is confusing - "On 2020-09-01T00:00:00Z, the validity period for Subscriber certificates MUST be less than or equal to 398 days, and SHOULD be less than or equal to 397 days." Why is the "SHOULD" phrase there?

The SHOULD is there to formally note the potential complications presented by UAs strictly enforcing validity periods which can include leap-seconds or similar "fuzzy" time increments. If a CA issues a certificate for the absolute maximum of 398 days, the risk is far greater than if they issue a certificate for an absolute maximum of 397 days, hence CAs should issue for a maximum below the maximum enforced by browsers or OSes.

[BenWilson-Mozilla]

Is there a prohibition on having a Sub CA where the EKU is just clientAuth? See: "For Subordinate CA Certificates that are not used to issue TLS certificates, then the values id-kp-serverAuth [RFC5280] and/or id-kp-clientAuth [RFC5280] MUST NOT be present."

[sleevi]

In light of the preceding bullet, I think this is confusing: "The reasonCode extension MUST NOT be present for unspecified revocations. RFC 5280 places this as a SHOULD, due to requiring an additional 12 bytes to encode the extension that is semantically equivalent to omitting it. The combination of requiring meaningful revocation reasons and wanting to ensure reasonably-sized CRLs means this value MUST NOT be present. (Section 7.2.2 (a))" Is this provision just for End Entity CRLs?

This is in the ballot description, not the text. Are you saying you found Section 7.2.2(a) confusing? Or that you found the description confusing?

This section describes two separate requirements. One is a requirement for how to encode a CRL reason - in any CRL. The other is a requirement that you must provide a reason for an intermediate.

These requirements, while separate, are meant to address confusion about CRL reasons, such as a CA thinking they could meet the first obligation by encoding "unspecified"

Also, this is confusing - "On 2020-09-01T00:00:00Z, the validity period for Subscriber certificates MUST be less than or equal to 398 days, and SHOULD be less than or equal to 397 days." Why is the "SHOULD" phrase there?

Beyond @clintwilson's remarks, this is clearly stated in Apple's policy: https://support.apple.com/en-us/HT211025
"We recommend that certificates be issued with a maximum validity of 397 days."

[sleevi]

Is there a prohibition on having a Sub CA where the EKU is just clientAuth? See: "For Subordinate CA Certificates that are not used to issue TLS certificates, then the values id-kp-serverAuth [RFC5280] and/or id-kp-clientAuth [RFC5280] MUST NOT be present."

Thanks for pointing that out. That was a typo that should have gotten fixed in 45208d9 which @clintwilson had spotted.

This is due to our existing (BRs) language around technically constrained sub-CA making it a certificate that only contains id-kp-clientAuth subject to the BRs (c.f. 7.1.2.2(g) in the version 1.6.9)

[timfromdigicert]

I think the OCSP signing EKU should be permitted in CA certificates to permit direct signing of OCSP responses. What was the reason for adding that to the excluded list of EKUs?

We agree. The OCSP-signing EKU is not prohibited by current Microsoft policy.

[sleevi]

We agree. The OCSP-signing EKU is not prohibited by current Microsoft policy.

I’m afraid you’re mistaken. I encourage you to cite what you believe permits it, but the current language is clear at https://aka.ms/rootcert 3.A.8

Issuing CA certificates that chain to a participating Root CA must be constrained to a single EKU

Of course, the current language only prohibits it in certificates used to issue TLS certificates. This is the only implementation that makes sense, and matches and aligns with existing practices of Mozilla.

ocspSigning only makes sense for delegated responders. Delegated responders do not need to issue TLS certificates. It’s actively harmful to allow delegated responders issue TLS certificates (e.g. nonces). This doesn’t prohibit delegated responders, but it makes it clear that such responders are not to be used for TLS issuance.

So there’s no need to permit joint ocspSigning and TLS. OcspSigning does not require EKU chaining. So there’s no plans to change this language, unless I’m missing an important caveat of policy or RFC6960 (and if so, please cite).

[sleevi]

Given that Microsoft announced this requirement with an immediate effective date at the Bratislava F2F, I don't see how this could be the intent of the requirement, otherwise a lot of CAs would immediately be out of compliance of Microsoft's Root Program on the announcement date.

To be fair, the root program change was made before the Bratislava update, so there was even greater risk of non-compliance ;)

However, as noted, the effective date here is intentional, because it permits scheduling and generating new CRLs.

Consider alternatives, such as "For revocations after {date X}". Such a requirement is ambiguous, such as whether it applies based on the revocationDate within the CRL, when the ceremony is performed, when the repository is updated, etc. This was trying to pick the least ambiguous date, and based on the existing requirement wording.