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 1 commit
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 names that will be listed in 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.
Copy link
Contributor

@bdaehlie bdaehlie Oct 21, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

This doesn't seem correct, but maybe I am misreading. With this edit we're saying that all names in the cert have been properly validated as controlled by the subscriber. What about the names of OCSP endpoints for example? Any other names in the certs like that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good point -- for example, the "CRLDistributionPoints" extension contains a GeneralName field, so definitely counts as a "name". That said, I borrowed this language from Section 3.2.2.4 of the BRs, which says "The CA SHALL confirm that prior to issuance, the CA has validated each Fully-Qualified Domain Name (FQDN) listed in the Certificate...:. CRLDPs are also FQDNs, but no one thinks that Section 3.2.2.4 means that they need to be validated as controlled by the Applicant.

What if we said "all names associated with the subject", meaning both in the subject and in subjectAltNames and any other future extensions, or something like that?

Copy link
Contributor

Choose a reason for hiding this comment

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

I just pointed out this same issue in another PR.

Maybe the most clear way to handle this is to create a defined term, like Subscriber Domains (I am not stuck on that particular wording). Then we can use the term in a number of places and there would be no ambiguity.

Copy link
Member

@beautifulentropy beautifulentropy 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.

Perhaps we can lift the phrase "every requested identifier" from Section 4.2.2.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Brainstorming other ideas:

  • Authorization Domain Name: By definition all the identifiers that we check are Authorization Domain names, and the BRs definition of that term defines it as "The FQDN used to obtain authorization for a given FQDN to be included in a Certificate.". So it gets a bit circular, but because OCSP and CRL URLs are not validated in the same way, they can't be Authorization Domain Names, so they wouldn't be included if we used that term.
  • "applied-for names": The BRs use this phrasing in the definition of "Base Domain Name". It has a very clear meaning, but is used less ubiquitously than "requested" (1 appearance vs 11).

I think I like Samantha's suggestion of using "requested" to qualify the names. It's simple, obvious, and reflects language used throughout the BRs.

Copy link
Member

Choose a reason for hiding this comment

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

"Authorization Domain Name" is the most viable alternative and I feel it's a little too verbose.


### 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