Bring profiles into the modern day

[aarongable]

Overhaul Section 7.1 Profiles, with two goals in mind:

• Removing deprecated pieces of our profiles, such as OCSP and the Internet Security Research Group Organization Name.
• Giving them the same format as the profiles in Section 7.1 of the Baseline Requirements.

Fixes #188
Fixes #304

[aarongable]

Preview the result here: https://github.com/letsencrypt/cp-cps/blob/aarongable-patch-1/CP-CPS.md#7-certificate-crl-and-ocsp-profiles

[jsha]

Diffing the Root CA Certificate section against the corresponding section in the BRs:

• For version, the BRs say "MUST be v3(2)" in the table; this branch refers out to a section.
• issuer: the branch carries over "meaningful CN", but that's not in the BRs. I'd recommend deleting it. Also, the branch says just "ISRG" but some pre-existing roots still spell out "Internet Security Research Group"; I think it makes sense to include both here.
• validity: the BRs refer out to a section; we inline it. Since a goal of this is closely matching the BRs, probably better to put our rules in a section to.
• subject: the language here says it's byte-for-byte identical to issuer, but the BRs have it the other way around: issuer is described as byte-for-byte identical to subject, and subject has the naming description.
• subjectKeyIdentifier - I think this is calculated differently for our old vs new roots and we should include both methods here.

[aarongable]

Diffing the Root CA Certificate section against the corresponding section in the BRs:

• For version, the BRs say "MUST be v3(2)" in the table; this branch refers out to a section.

Yes, that's because we don't want to say the same thing in multiple places. The BRs, on the other hand, are happy to do so: they repeat the same "MUST be v3" language in both 7.1.1 and 7.1.2.x.

• issuer: the branch carries over "meaningful CN", but that's not in the BRs. I'd recommend deleting it. Also, the branch says just "ISRG" but some pre-existing roots still spell out "Internet Security Research Group"; I think it makes sense to include both here.

Good point re: "meaningful"; I think we should replace it with "unique" since that's what the BRs ask for: "The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate."

I specifically removed all aspects of these profiles that pertain to our old root and intermediate certificates. Although we are still using them, they were issued under an older version of our CP/CPS, and therefore still comply. The CP/CPS, like the BRs, governs the certificates we issue, not the ones we happen to be using.

• validity: the BRs refer out to a section; we inline it. Since a goal of this is closely matching the BRs, probably better to put our rules in a section to.

I previously agreed with this stance, and tried to break everything out into sections like the BRs do. It felt even more confusing, because the BRs subsections are in arbitrary orders (since some are unique to specific profiles, while others are shared across profiles), and we cannot match the BRs sub-sub-subsection numbering. I think that this simplified, inlined version is actually easier to cross-reference with the BRs, due to only having to jump around within one doc, rather than both.

• subject: the language here says it's byte-for-byte identical to issuer, but the BRs have it the other way around: issuer is described as byte-for-byte identical to subject, and subject has the naming description.

Good point, I'll reverse it.

• subjectKeyIdentifier - I think this is calculated differently for our old vs new roots and we should include both methods here.

See reply above about not describing our old issuance practices anymore.