Proposal: Make OCSP Optional, Require CRLs, and Incentivize Automation / Short-Lived Certificates

[ryancdickson]

This pull request is a follow-up to #402, which inadvertently made edits to the in-progress "profiles" branch.

Due to conflicts, #402 was closed. Since closing #402, a separate branch (i.e., "make-ocsp-optional") has been created dedicated to this specific proposal. Comments made on #402 will be transposed here.

Background, motivation, and additional information is available here.

This "Pull Request" is intended to be used to foster discussion within the community in advance of requesting endorsors and beginning the balloting process.

[aarongable]

LGTM. Looking at this with fresh post-vacation eyes caught one more phrasing thing, and then I finally allowed myself to comment on the formatting nits that don't affect the meaning of the ballot.

[aarongable]

I think it's fine to have this bullet point here (since it's historically been here), but I think it could also just be omitted because it's repeated in the table in Section 7.2.

The same applies for CAs issuing CA Certificates below.

[ryancdickson]

I appreciate that perspective.

I originally kept the language in 4.9.7 for consistency with the existing location in the BRs. However, now that this requirement is addressed in the CRL profile, the redundancy may create more headache than it's worth (i.e., if the nextUpdate period were to change in the future, we'd need to address it in two sections).

Addressed in: ryancdickson@9615372

[aarongable]

I still find this phrasing slightly confusing. Simplifying the sentence, it says "CAs MUST update and publish a new CRL within at least seven/four days." Within seven/four days of what? We know that it means "within seven/four days of publishing the previous version of the CRL", but it doesn't actually say that. The previous text said "once every seven days". Maybe we could borrow that language:

Suggested change

	1. MUST update and publish a new CRL within at least:
	- seven (7) days if all Certificates include an Authority Information Access extension with an id-ad-ocsp accessMethod (“AIA OCSP pointer”); or
	- four (4) days in all other cases;
	1. MUST update and publish a new CRL:
	- every seven (7) days if all Certificates include an Authority Information Access extension with an id-ad-ocsp accessMethod (“AIA OCSP pointer”); or
	- every four (4) days in all other cases;

The same applies for CAs issuing CA Certificates below.

[dzacharo]

If we don't use "at least every X days" then if a CA decides to publish a new CRL sooner it would violate the requirement.

[aarongable]

Ah good catch, then I'm in favor of replacing "within at least" with "at least every".

[ryancdickson]

@aarongable and @dzacharo - any issues with this proposed update?

[aarongable]

Suggested change

	When present, the CRL Distribution Points extension MUST contain at least one `DistributionPoint`; containing more than one is NOT RECOMMENDED. All `DistributionPoint` items must be formatted as follows:
	When present, the CRL Distribution Points extension MUST contain at least one `DistributionPoint`; containing more than one is NOT RECOMMENDED. All `DistributionPoint` items MUST be formatted as follows:

maybe? I'm not sure why this "must" wasn't capitalized previously.

[ryancdickson]

It was a typo on my part dating back to the early versions of the proposal.

[aarongable]

nit: column alignment

Suggested change

	| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. |
	| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. |

[ryancdickson]

Addressed in ryancdickson@bbf5155.

[aarongable]

nit: column alignment

Suggested change

	| __Field__ | __Presence__ | __Description__ |
	| --- | ------ | ------ |
	| `tbsCertList` | | |
	|     `version` | MUST | MUST be v2(1), see [Section 7.2.1](#721-version-numbers) |
	|     `signature` | MUST | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) |
	|     `issuer` | MUST | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. |
	|     `thisUpdate` | MUST | Indicates the issue date of the CRL. |
	|     `nextUpdate` | MUST | Indicates the date by which the next CRL will be issued. For CRLs covering Subscriber Certificates, at most 10 days after the `thisUpdate`. For other CRLs, at most 12 months after the `thisUpdate`. |
	|     `revokedCertificates` | * | MUST be present if the CA has issued a certificate that has been revoked and the corresponding entry has yet to appear on at least one regularly scheduled CRL beyond the revoked certificate's validity period. The CA SHOULD remove an entry for a corresponding certificate after it has appeared on at least one regularly scheduled CRL beyond the revoked certificate's validity period. See the "revokedCertificates Component" table for additional requirements. |
	|     `extensions` | MUST | See the "CRL Extensions" table for additional requirements. |
	| `signatureAlgorithm` | MUST | Encoded value MUST be byte-for-byte identical to the `tbsCertList.signature`. |
	| `signature` | MUST | - |
	| Any other value | NOT RECOMMENDED | - |
	| __Field__ | __Presence__ | __Description__ |
	| --- | ------ | ------ |
	| `tbsCertList` | | |
	|     `version` | MUST | MUST be v2(1), see [Section 7.2.1](#721-version-numbers) |
	|     `signature` | MUST | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) |
	|     `issuer` | MUST | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. |
	|     `thisUpdate` | MUST | Indicates the issue date of the CRL. |
	|     `nextUpdate` | MUST | Indicates the date by which the next CRL will be issued. For CRLs covering Subscriber Certificates, at most 10 days after the `thisUpdate`. For other CRLs, at most 12 months after the `thisUpdate`. |
	|     `revokedCertificates` | * | MUST be present if the CA has issued a certificate that has been revoked and the corresponding entry has yet to appear on at least one regularly scheduled CRL beyond the revoked certificate's validity period. The CA SHOULD remove an entry for a corresponding certificate after it has appeared on at least one regularly scheduled CRL beyond the revoked certificate's validity period. See the "revokedCertificates Component" table for additional requirements. |
	|     `extensions` | MUST | See the "CRL Extensions" table for additional requirements. |
	| `signatureAlgorithm` | MUST | Encoded value MUST be byte-for-byte identical to the `tbsCertList.signature`. |
	| `signature` | MUST | - |
	| Any other value | NOT RECOMMENDED | - |

[ryancdickson]

Addressed in ryancdickson@bbf5155.

[aarongable]

nit: column alignment

Suggested change

	| __Extension__ | __Presence__ | __Critical__ | __Description__ |
	| ---- | - | - | ----- |
	| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) |
	| `CRLNumber` | MUST | N | MUST contain an INTEGER greater than or equal to zero (0) and less than 2¹⁵⁹, and convey a strictly increasing sequence. |
	| `IssuingDistributionPoint` | * | Y | See [Section 7.2.2.1 CRL Issuing Distribution Point](#7221-crl-issuing-distribution-point) |
	| Any other extension | NOT RECOMMENDED | - | |
	| __Extension__ | __Presence__ | __Critical__ | __Description__ |
	| ---- | - | - | ----- |
	| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) |
	| `CRLNumber` | MUST | N | MUST contain an INTEGER greater than or equal to zero (0) and less than 2¹⁵⁹, and convey a strictly increasing sequence. |
	| `IssuingDistributionPoint` | * | Y | See [Section 7.2.2.1 CRL Issuing Distribution Point](#7221-crl-issuing-distribution-point) |
	| Any other extension | NOT RECOMMENDED | - | |

[ryancdickson]

Addressed in ryancdickson@b2df5dc.

[aarongable]

nit: empty line after header

Suggested change

	#### 7.2.2.1 CRL Issuing Distribution Point
	#### 7.2.2.1 CRL Issuing Distribution Point

[ryancdickson]

Addressed in ryancdickson@bbf5155.

[aarongable]

nit: column width

Suggested change

	| __Component__ | __Presence__ | __Description__ |
	| ---- | - | ----- |
	| `serialNumber` | MUST | MUST be byte-for-byte identical to the serialNumber contained in the revoked certificate. |
	| `revocationDate` | MUST | Normally, the date and time revocation occurred. See the footnote following this table for circumstances where backdating is permitted. |
	| `crlEntryExtensions` | * | See the "crlEntryExtensions Component" table for additional requirements. |
	| __Component__ | __Presence__ | __Description__ |
	| ---- | - | ----- |
	| `serialNumber` | MUST | MUST be byte-for-byte identical to the serialNumber contained in the revoked certificate. |
	| `revocationDate` | MUST | Normally, the date and time revocation occurred. See the footnote following this table for circumstances where backdating is permitted. |
	| `crlEntryExtensions` | * | See the "crlEntryExtensions Component" table for additional requirements. |

[ryancdickson]

Addressed in ryancdickson@bbf5155.

[wthayer]

What about CAs that shard CRLs but do not include the cRLDP in the certs? I don't think the intent is to prohibit that but this language seems to have that effect? Can we add something like 'or at least one of the URLs published in CCADB'? Also, in either case is there a chicken/egg problem here if CRLs are issued before certs or before CCADB is updated?

[ryancdickson]

My interpretation of: "Partitioned CRLs MUST include at least one of the names from the corresponding distributionPoint field of the cRLDistributionPoints extension of every certificate that is within the scope of this CRL. The encoded value MUST be byte-for-byte identical to the encoding used in the distributionPoint field of the certificate."

• If certificates DO contain a distributionPoint field and that name points to a partitioned CRL, that same name must appear in a corresponding CRL (in the Issuing Distribution Point extension).
• If certificates DO NOT contain a distributionPoint field (because there is no cRLDistributionPoints extension), neither statement applies. Regardless, if a CA issues partitioned CRLs, they are obligated to ensure that when those partitioned CRLs are aggregated, they represent the equivalent of a full and complete CRL.

7.1.2.11.2 (“CRL Distribution Points”) indicates that CRLDP is required for certificates that 1) do not qualify as "Short-lived Subscriber Certificates" and 2) do not include an Authority Information Access extension with an id-ad-ocsp accessMethod. This helps clarify the expectation that certificates can exist without CRLDP.

---

Can we add something like 'or at least one of the URLs published in CCADB'?

---> the concept of the CCADB is not known to the BRs. I sense this might be by design, as not all CAs who wish to conform with the BRs might have access to the CCADB, or a desire to disclose information publicly to the CCADB.

---

Also, in either case is there a chicken/egg problem here if CRLs are issued before certs or before CCADB is updated?

---> I'm not sure I understand the problem. Can you share more?

BRs (as proposed):

• Within 24 hours after issuing its first certificate, the CA must generate and publish a CRL (full and complete or partitioned)

Apple/Mozilla program requirements extend this by requiring disclosure of those URLs to CCADB within 7 days:

• Apple: "Effective October 1, 2022, CA providers must populate the CCADB fields under "Pertaining to Certificates Issued by This CA" with either the CRL Distribution Point for the "Full CRL Issued By This CA" or a "JSON Array of Partitioned CRLs" on Root and Intermediate Certificate records, within 7 days of the corresponding CA issuing its first certificate. This requirement applies to each included CA Certificate and each CA Certificate chaining up to an included CA Certificate in the Apple Root Program."
• Mozilla: "CA operators with intermediate CA certificates that are capable of issuing TLS certificates chaining up to root certificates in Mozilla's root store SHALL populate the CCADB fields under "Pertaining to Certificates Issued by This CA" with either the CRL Distribution Point for the "Full CRL Issued By This CA" or a "JSON Array of Partitioned CRLs" within 7 days of such intermediate CA issuing its first certificate;"

As of a few weeks ago, there were at least 25 CRLs disclosed to CCADB that contained 0 revoked certificate entries. I’d have to look again to see if these CAs issued any certificates, but I’m not sure it matters.

[wthayer]

My fundamental concern is that someone could come along in the future and interpret this section as an implicit requirement to include the cRLDP extension in certs when a CA is issuing sharded CRLs. Perhaps an easy clarification that aligns with your interpretation of the language is to prepend "If certificates contain a distributionPoints field and that name points to a partitioned CRL,..."

[ryancdickson]

Fair point. Re-phrased, with that concern in mind:

"If a Certificate contains a distributionPoint field that does not point to the URI of a full and complete CRL, the corresponding CRL MUST contain the issuingDistributionPoint extension (OID 2.5.29.28). The encoded value of the issuingDistributionPoint extension MUST be byte-for-byte identical to the encoding used in the distributionPoint field of the Certificate."

Any concerns with this approach?

[wthayer]

LGTM

[ryancdickson]

Thanks @wthayer!

CC @aarongable and @CBonnell - as I believe during past discussions you both had opinions on the language re: IDP. Any concerns with the above change? Candidly, I'd like this next round of discussion to be the last, so the more opinions, the better.

[CBonnell]

I understand the intent behind the change, but the concern I have with the proposed language is that other GeneralNames cannot be included in the IDP extension (as the value of the extension itself must be binary equal to the single distributionPoint).

I suggest:

Partitioned CRLs MUST contain an Issuing Distribution Point extension. The distributionPoint field of the Issuing Distribution Point extension MUST be present. Additionally, the fullName field of the DistributionPointName value MUST be present, and its value MUST conform to the following requirements:

1. If a Certificate within the scope of the CRL contains a CRL Distribution Points extension, then at least one of the uniformResourceIdentifiers in the CRL Distribution Points's fullName field MUST be included in the fullName field of the CRL's Issuing Distribution Point extension. The encoding of the uniformResourceIdentifier value in the Issuing Distribution Point extension SHALL be octet-for-octet identical to the encoding used in the Certificate's CRL Distribution Points extension.
2. Other GeneralNames of type uniformResourceIdentifier MAY be included.
3. Non-uniformResourceIdentifier GeneralName types MUST NOT be included.

[ryancdickson]

Thanks, @CBonnell. I think that works and still addresses @wthayer's earlier concern.

Aside from one small change (using "byte-for-byte" in lieu of "octet-for-octet" --- to avoid introducing a new term), I believe I incorporated your feedback "as-is."

I made some other small tweaks to improve consistency in how extensions introduced in this update are represented.

[wthayer]

Nit, but I had to read this language a few times to get comfortable with it. I think a statement like 'the unspecified reason is represented by the omission of a reasonCode.' would add clarity.

[ryancdickson]

Addressed in ryancdickson@530bc88

The "Description" column now reads: "Represented by the omission of a reasonCode. MUST be omitted if the CRL entry is for a Certificate not technically capable of causing issuance unless the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to July 15, 2023."

@wthayer, does this work for you?

[wthayer]

LGTM