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

Remove references to certificate contents from issuance process #245

Merged
merged 4 commits into from
Oct 23, 2024
Merged

Remove references to certificate contents from issuance process #245

Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
32c1d8f
Remove references to certificate contents from issuance process
aarongable Oct 18, 2024
c233cb3
Use "requested names"
aarongable Oct 22, 2024
172c10e
Fix typo
aarongable Oct 22, 2024
1812a4b
Reduce mentions of CT in 4.4.2
aarongable Oct 22, 2024
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
4 changes: 2 additions & 2 deletions CP-CPS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -314,7 +314,7 @@ No stipulation.

### 4.3.1 CA actions during certificate issuance

At a high level, the following steps are taken during issuance of a Subscriber Certificate. ISRG's automated processes confirm that all names which will appear in the Common Name and/or list of SANs of the certificate have been properly validated to be controlled by the Subscriber requesting the certificate. The to-be-signed certificate is linted, then signed by a Subordinate CA in an HSM. After issuance is complete, the certificate is stored in a database and made available to the Subscriber.
At a high level, the following steps are taken during issuance of a Subscriber Certificate. ISRG's automated processes confirm that all requested names have been properly validated to be controlled by the Subscriber requesting the certificate. The to-be-signed certificate is linted, then signed by a Subordinate CA in an HSM. After issuance is complete, the certificate is stored in a database and made available to the Subscriber.
Copy link

Choose a reason for hiding this comment

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

I worry about using a non-defined term "names" here. While intuitively I know what it means (CN and SANs), I worry it could be unclear. For example, is an IP Address a name? (yes: it's a SAN, but is it well defined enough to make that clear?)

Copy link
Contributor

Choose a reason for hiding this comment

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

It makes me uncomfortable as well because of the lack of clarity that Matthew mentioned, the plain English reading is confusing, and it raises the question of "requested by who?" without a readily available answer.

"requested names" is a clear improvement over what we had before with minimal work but we should probably take it further. If there is a reason to postpone a more complete solution for the future though, I could live with it for now.

Copy link
Contributor Author

@aarongable aarongable Oct 22, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

I think the definition of "name" here is "anything encoded as an ASN.1 GeneralName". The term is used that way throughout the BRs already:

The permittedSubtrees MUST contain at least one GeneralSubtree for both of the dNSName and iPAddress GeneralName name types, UNLESS the specified GeneralName name type appears within the excludedSubtrees to exclude all names of that name type.

CAs SHALL NOT include additional names unless the CA is aware of a reason for including the data in the Certificate.

High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage

including one that explicitly counts IP Addresses as names:

CAs SHALL NOT issue certificates containing Internal Names or Reserved IP Addresses, as such names cannot be validated according to Section 3.2.2.4 or Section 3.2.2.5.

jsha marked this conversation as resolved.
Show resolved Hide resolved

### 4.3.2 Notification to subscriber by the CA of issuance of certificate

Expand All @@ -332,7 +332,7 @@ See Section 2.2 of this document for Root and Subordinate CA certificate publica

All Subscriber Certificates are made available to Subscribers via the ACME protocol.

For each Subscriber Certificate issuance, ISRG signs a Precertificate and submits it to a selection of Certificate Transparency logs. Upon successful submission, ISRG attempts to issue a certificate that matches the Precertificate (per RFC 6962 Section 3.1) and embeds at least two of the resulting Signed Certificate Timestamps (SCTs). ISRG submits the resulting final certificate to a selection of Certificate Transparency logs on a best-effort basis.
Prior to each Subscriber Certificate issuance, ISRG signs a corresponding Precertificate and submits it to a selection of Certificate Transparency logs. After each Subscriber Certificate issuance, ISRG submits resulting certificate to a selection of Certificate Transparency logs on a best-effort basis.
aarongable marked this conversation as resolved.
Show resolved Hide resolved

ISRG does not guarantee issuance of a final certificate for every Precertificate.

Expand Down
Loading