Remove references to certificate contents from issuance process

[aarongable]

Sections 4.3.1 and 4.4.2 do not need to describe certificate contents, only the actions undertaken to issue those certificates.

[bdaehlie]

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?

[aarongable]

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?

[bdaehlie]

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.

[beautifulentropy]

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

[aarongable]

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.

[beautifulentropy]

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

[mcpherrinm]

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?)

[bdaehlie]

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.

[aarongable]

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.