Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SC-58: Require distributionPoint in sharded CRLs #396

Merged
merged 4 commits into from
Nov 11, 2022
Merged

SC-58: Require distributionPoint in sharded CRLs #396

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
7b3d082
SC-XX: Require distributionPoint in sharded CRLs
aarongable Oct 14, 2022
5a6f056
Remind readers that the IDP must be critical
aarongable Oct 17, 2022
23bb1e8
Change effective date to Jan 15
aarongable Oct 17, 2022
348756d
Change effective date in Section 1.2 table, too
aarongable Oct 17, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions docs/BR.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -174,6 +174,7 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o
| 2021-12-01 | 3.2.2.4 | CAs MUST NOT use methods 3.2.2.4.6, 3.2.2.4.18, or 3.2.2.4.19 to issue wildcard certificates or with Authorization Domain Names other than the FQDN. |
| 2022-06-01 | 7.1.3.2.1 | CAs MUST NOT sign OCSP responses using the SHA-1 hash algorithm. |
| 2022-09-01 | 7.1.4.2.2 | CAs MUST NOT include the organizationalUnitName field in the Subject |
| 2023-01-15 | 7.2.2 | Sharded or partitioned CRLs MUST have a distributionPoint |

## 1.3 PKI Participants

Expand Down Expand Up @@ -2312,6 +2313,10 @@ Prior to including a Reserved Certificate Policy Identifier, the CA MUST ensure
If a CRL entry is for a Certificate subject to these Requirements, the `CRLReason` MUST NOT be certificateHold (6).

If a `reasonCode` CRL entry extension is present, the `CRLReason` MUST indicate the most appropriate reason for revocation of the certificate, as defined by the CA within its CP/CPS.

2. `issuingDistributionPoint` (OID 2.5.29.28)

Effective 2023-01-15, if a CRL does not contain entries for all revoked unexpired certificates issued by the CRL issuer, then it MUST contain a critical Issuing Distribution Point extension and MUST populate the `distributionPoint` field of that extension.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be helpful to include the specification for the distributionPoint field value directly or through reference to RFC 5280 §4.2.1.13.

Copy link
Contributor Author

@aarongable aarongable Oct 21, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am following the example of 7.2.2 (1) reasonCode above, which simply makes statements about when the Reason Code field must appear and what values it can hold.


## 7.3 OCSP profile

Expand Down