SC-062 Profiles: Address various editorial and content nits

[aarongable]

This PR contains proposed fixes for all of the feedback items I raised in https://lists.cabforum.org/pipermail/servercert-wg/2023-February/003551.html. Reproducing those items here:

Editorial notes:

• GitHub-flavored markdown does not support 2^159^ for exponentiation. Consider Unicode SUPERSCRIPT numerals (i.e. 2¹⁵⁹)?
• GitHub-flavored markdown does not support \ \ \ \ inside tables for indentation. Consider Unicode non-breaking figure spaces (i.e.     foo)?
• The [^surname_givenname] footnote entry needs to be followed by a colon (i.e. [^surname_givenname]:) to be properly linked and rendered by GitHub-flavored markdown.
• Use of "e.g." to mean "approximately" in "2922 days (e.g. 8 years)" is not appropriate. Consider using "approx." instead.
• 7.1.2.1.1 has the name "Root CA Validity", but 7.1.2.1.3 just has the name "Authority Key Identifier". Either both of these should be prefaced with "Root CA" to disambiguate them from sections regarding the same fields but for other certificate types, or neither of these should be prefaced with "Root CA" as that qualifier is implied by being under section 7.1.2.1 Root CA Certificate Profile. The same applies to many other subsection titles.
• In 7.1.2.2.3, the tables only differ in one row. I believe it would be beneficial to readers to make the first table apply to all Subordinate CA Certificates, and then follow it with a single-row table that overrides that one row for the case that the Subordinate CA is operated externally.
• In 7.1.2.7.6, a dash (-) is used to indicate that the criticality of the subjectAltName extension depends on other factors. However, in earlier tables for CA certificate extensions (e.g. 7.1.2.2.3), an asterisk and footnote is used to indicate that the criticality depends on other factors. These should use the same notation as each other. I personally think the best notation is simply an asterisk, with all additional context provided in the "See Section X" section.
• In 7.1.2.7.12, the table entry for dnsName uses sentences phrased "The entry MUST", but the iPAddress table entry uses sentences which simply start "MUST ...". These should use similar phrasing.
• 7.1.2.8.4 includes a note regarding DER encoding of optional fields which take their default value. It seems odd to include this under Delegated OCSP Responder Certs but not under 7.1.2.7.8 Subscriber Certificate Basic Constraints, which has the same table. Also, is there a reason that this note doesn't simply say that, in this case, the extension must have the value NULL? Why is deriving this left as an exercise for the reader?
• Speaking of which, 7.1.2.8.6 and 7.1.2.9.3 use very different language to describe the ocsp-nocheck and precertificate-poison extensions having the value NULL. These should use the same language as each other.
• The tables in 7.1.2.11.2 seem confusing. Personally, I would include tables profiling the inner DistributionPoint and uniformResourceIdentifier objects, and use non-tabulated language to describe the fact that including more than one entry in the outer CRLDistributionPoints and fullName objects is NOT RECOMMENDED.

Substantive content notes:

• 7.1.2.2 says that it applies when creating a cross-sign for either an existing Root CA Certificate or an existing Subordinate CA Certificate. However, the definition of "Cross-Certificated Subordinate CA Certificate" in Section 1.6.1 still just says that it establishes trust "between two Root CAs". I believe the definition should be updated to indicate that it establishes trust between any two CAs, not just between two Root CAs.
• I'm curious about why the nameConstraints extension, if present, MUST contain a permittedSubtree for directoryNames. I think this means that Technically Constrained can only apply to Subordinate CA Certs which conduct OV/EV issuance?
• 7.1.2.7.7 refers to "AuthorityInformationAccessSyntax", but the ASN.1 type declared in RFC 5280 Section 4.2.2.1 is actually "AuthorityInfoAccessSyntax". The same in 7.1.2.10.3.
• Section 7.1.2.7.9 says other policy identifiers "MUST be defined by the CA". What if the policy identifier is defined by a different CA, which cross-signed the issuing CA and requires this policy identifier as part of that cross-sign contract?
• Section 7.1.2.9 says that "two Precertificates [cannot] share the same serialNumber, unless they are byte-for-byte identical, as this would otherwise indicate that there are corresponding Certificates that share the same serialNumber". I admit that this is a bizarre corner case, but: what if an Issuing CA has two Technically Constrained Precertificate Signing CAs? They could each issue a Precertificate with all of the same fields except for the Issuer field and authorityKeyIdentifier extension. But the Precertificate<->Certificate transformation would wipe out those changes, indicating that both Precertificates correspond to the same Certificate, and thus no violation of the serialNumber uniqueness constraint has occurred. Maybe nothing needs to change here, but maybe it's worth workshopping this language to avoid this confusion.
• Section 7.1.2.11.2 uses different language to describe the first uniformResourceIdentifier and subsequent uniformResourceIdentifiers in a fullName. In particular, the emphasis of the "MUST be http" in the 2+ section makes it seem like HTTP is not a MUST for the first entry.

In general, each commit on this branch addresses one bullet point in the list above, in order from top to bottom.

[aarongable]

I have confirmed that using unicode superscript for exponentiation and unicode nonbreaking figure space for table indentation both work in the rendered PDF as well.

[ryancdickson]

Justification for change (for other readers):

7.1.2.2 says that it applies when creating a cross-sign for either an existing Root CA Certificate or an existing Subordinate CA Certificate. However, the definition of "Cross-Certificated Subordinate CA Certificate" in Section 1.6.1 still just says that it establishes trust "between two Root CAs". I believe the definition should be updated to indicate that it establishes trust between any two CAs, not just between two Root CAs.

My opinion: I agree, and this also offers better alignment with RFC 5280...

   CA certificates in which the issuer and subject are different
   entities.  Cross-certificates describe a trust relationship between
   the two CAs. 

[CBonnell]

I agree with you both that the current definition of "Cross-certified" in the BRs is problematic as it does not align with the RFC 5280 definition.

However, this change should be weighed carefully, as there are explicit carve-outs/allowances for Root<-Root cross-certs in these profiles. For example, I believe this modification would allow any internally-controlled SubCA to not contain the EKU extension.

[aarongable]

Hmm, that's a good point. In 1.8.6, the language is:

For Cross Certificates that share a Subject Distinguished Name and Subject Public Key with a Root Certificate operated in accordance with these Requirements, this extension MAY be present.

So the carve-out is based on it both meeting the criteria for a Cross Certificate and sharing a name+key with a Root Certificate. But in this profiles branch, the carve-out is based solely on if the Cross-Certified Subordinate CA is operated internally:

The acceptable extensions and the requirements for those extensions in a Cross-Certified Subordinate CA vary based on whether or not the Subordinate CA is issued to and operated by the same organization as the Issuing CA or an Affiliate of the Issuing CA organization.

I'm sorry that I haven't followed the development of this profiles ballot closely enough; I'm sure this has been discussed previously. What's the reasoning for this change from "matches a Root" to "is internally operated" for making extKeyUsage a SHOULD instead of a MUST?

edit: Oh, I think I get it. The idea is that it's not a change: the requirement of "matches a Root" was previously redundant because it was already implicitly contained in the definition of a Cross Certificate. My changing the definition here would simply require that the "matches a Root" requirement be re-added to the carve-out, to maintain parity with 1.8.6. I think.

[timfromdigicert]

This is a bit of a mess. The key factor here is whether the cross certificate crosses an organizational boundary or not. There's an obvious difference between one organization cross signing CAs internally, and cross signing the CA certificate of another organization, root or otherwise. There's also the problem we never fixed of the difference between CA Organizations and CA Certificates which always makes reading these things a nightmare. Is an internally cross sign a CC-S-CA-C? It depends on whether you read CA=CAC or CA=CAO. Ick.

The "cross sign between roots" language obviously was written by someone a while back who wasn't thinking about internal cross signs or cross signing ICAs, which honestly was the way most people were thinking back when most of this was written. We need to be a bit careful to make sure the updates in this area are done carefully.

[aarongable]

At the end of the day, the new Cross-Certified Subordinate CA Certificate Profile (7.1.2.2) already says

This Certificate Profile MAY be used when issuing a CA Certificate using the same Subject Name and Subject Public Key Information as one or more existing CA Certificate(s), whether a Root CA Certificate or Subordinate CA Certificate.

Therefore the bit that @CBonnell objected to (allowing an internally-controlled SubCA to not contain the EKU extension) is already the case in the Profiles ballot. My change to the definition up here doesn't affect that.

If we want to address that, then let's do so, but in the mean time can we harmonize the definition of Cross-Certified Subordinate CA Certificate with the explicit language of the section which concerns it?

[ryancdickson]

I attempted to trace Version 1.8.6 of the BRs, the original set of proposed SC-062 changes, and those also suggested by @aarongable.

In summary, I agree with Aaron and think changes could be made to ensure consistency with the existing BRs for externally operated scenarios (“matches an existing Root, externally operated: SHOULD have extKeyUsage, MUST NOT contain anyExtendedKeyUsage”).

Suggested updates for consistency with 1.8.6 (additive to Aaron’s proposed changes):

• 7.1.2.2.3 (Cross-Certified Subordinate CA Extensions):

  • Update the third table describing “the extKeyUsage extension when the Subordinate CA is operated by an entity that is not the Issuing CA or an Affiliate of the Issuing CA” to change extKeyUsage MUST to SHOULD

• 7.1.2.2.5 (Extended Key Usage - Restricted Cross-Certified CA):

  • Add clarification: “Restricted Cross-Certified CA Certificates that will be used to issue TLS certificates MUST contain the key purpose id-kp-serverAuth.”

This would allow Cross Certificates issued to externally operated roots to optionally include EKU (consistent with Version 1.8.6), while also constraining Cross Certificates to externally operated ICAs that issue TLS certificates to minimally require serverAuth.

@aarongable do you see it the same way?

General comment: the Chrome Root Program policy requires hierarchies accepted into the Chrome Root Store after 9/1/2022 (program launch date) to be dedicated to TLS use cases. The absence of EKU in a subordinate CA certificate chaining to a root added to the Chrome Root Store after 9/1/2022 would be a violation of the Chrome Root Program Policy.

While we prefer extKeyUsage as a MUST in all non-root CA certificates, not all CAs following the BRs intend to be included in the Chrome Root Store.

[ryancdickson]

Update: As I re-read my last comment, I now realize I missed something.

BRs Version 1.8.6, 7.1.2.2 G:

• "For Cross Certificates that share a Subject Distinguished Name and Subject Public Key with a Root Certificate operated in accordance with these Requirements, this extension [EKU] MAY be present."
• (continues) "This extension MAY contain the anyExtendedKeyUsage [RFC5280] usage, if the Root Certificate(s) associated with this Cross Certificate are operated by the same organization as the issuing Root Certificate."

I interpret this to imply: "Cross Certificates issued to Root CAs NOT operated by the same organization as the issuing Root Certificate MUST NOT contain the anyExtendedKeyUsage [RFC5280] usage [or the equivalent of not defining any EKUs]."

To that end, I think my comments above re: changes to 7.1.2.2.3 (Cross-Certified Subordinate CA Extensions) are incorrect - and the only proposed changes should be to 7.1.2.2.5, now suggested as follows:

7.1.2.2.5 (Extended Key Usage - Restricted Cross-Certified CA):

• Remove "If present" from "If present, the Extended Key Usage extension MUST only contain key usage purposes for which the Issuing CA has verified the Cross-Certified Subordinate CA is authorized to assert."
• Add clarification: “Restricted Cross-Certified CA Certificates that will be used to issue TLS certificates MUST contain the key purpose id-kp-serverAuth.”

[dzacharo]

@ryancdickson , regarding:

The absence of EKU in a subordinate CA certificate chaining to a root added to the Chrome Root Store after 9/1/2022 would be a violation of the Chrome Root Program Policy

What is the purpose of requiring an EKU in CA Certificates if the entire hierarchy is restricted to TLS (at the Trust Anchor level)? It adds bytes on the wire for each TLS handshake and brings no security benefit. If I remember correctly, the purpose of adding that EKU was to restrict applicable policies in multi-purpose hierarchies. If the hierarchy is TLS-only, I don't see any reason to require this EKU for CA Certificates.

When creating cross-certificates to multi-purpose Roots, then it makes more sense to further restrict via EKU.

[ryancdickson]

@dzacharo

The statement “If the hierarchy is restricted to TLS (at the Trust Anchor level)” might assume there is a capability to distinguish the hierarchical restriction by the verifier outside of the content included in the root CA certificate. For Application Software Suppliers, or their corresponding customers, that do not or can not use metadata, I’m not aware of any content within the root CA certificate alone that would strongly signal how the hierarchy should be constrained (to be clear, I do not consider including “TLS” in the subject DN a strong signal).

Regardless of specific Application Software Supplier implementations, it would seem the BRs (existing today and the proposed update) agree with our program policy that EKU is required on subordinate CA certificates with one exception (cross certificates whose represented issuer and subject CAs are both roots and operated by the same organization - described below).

BRs Section 1.8.6, 7.1.2.2 (Subordinate CA Certificate), Part G: "For all other Subordinate CA Certificates, including Technically Constrained Subordinate CA Certificates: This extension MUST be present and SHOULD NOT be marked critical."

The only subordinate CA certificates described prior to the above statement are:

• cross certificates whose represented issuer and subject CAs are (A) both roots and (B) operated by the same organization; and
• cross certificates whose represented issuer and subject CAs are (A) both roots and (B) operated by different organizations.

As to why I think cross certificates whose represented issuer and subject CAs are (A) both roots and (B) operated by different organizations require an explicit EKU:

(1) BRs Section 1.8.6, 7.1.2.2 (Subordinate CA Certificate), Part G states: "This extension MAY contain the anyExtendedKeyUsage [RFC5280] usage, if the Root Certificate(s) associated with this Cross Certificate are operated by the same organization as the issuing Root Certificate."

(2) If we imagined three identical certificates with only the following differences:

• Certificate Number 1: expresses no EKU
• Certificate Number 2: expresses an EKU with a purpose of anyExtendedKeyUsage
• Certificate Number 3: expresses the set of all known EKUs (if this was possible)

How would an RFC 5280-compliant certificate verifier (if we can use such a term) treat them? If EKU (Section 4.2.1.12) of 5280 “indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension” my interpretation is that they should be treated the same (i.e., they are “operationally” equivalent).

(3) only cross certificates where issuer/subject are operated by the same organization are permitted to include anyEKU (i.e., number 1), or by transitive property, express no EKU (i.e., number 2).

(4) If it was intended that cross certificates issued to external CAs did not require an explicit set of EKUs, the same exception allowing anyEKU described above (i.e., number 1) would have been made.

[1] Footnote on Pg. 75 of Version 1.8.6 of the BRs: "While RFC 5280, Section 4.2.1.12 notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers."

Hopefully this also more clearly describes the position in my earlier comment.

[dzacharo]

I am not challenging what the current BRs say or what the current Root Store policies says. My comment is about native TLS hierarchies. Non-Browser implementations don't check the EKU at the CA level anyway. In the future, if there were native TLS hierarchies, including the EKU extension in a CA doesn't "further protect relying parties" because they are protected by the actual design of the "nativeness" of the hierarchy.

So, if a CA knows that it manages such a native TLS hierarchy, perhaps it would make sense to consider removing that requirement in the future at the CA level, because it doesn't add any benefits, but leave it for hierarchies that are mixed.

Anyway, my comment was mostly about Google Chrome's Policy which is TLS-only and already pushing for native TLS hierarchies.

[CBonnell]

@aarongable, that's a great call-out, as the allowance on excluding the EKU in a SubCA whose name and SPKI do not correspond to a Root is seemingly a regression in this branch. Additionally, it would still run afoul of MozPol.

IIRC, the intent of the "whether a Root CA Cert or SubCA Cert" was to encompass issuance where the Root CA signs an externally-operated subCA. In this case, it is deemed desirable to enforce EKU constraints on the external entity's CA. As you pointed out, this introduced a seeming regression/defect in the proposed BR language.

[ryancdickson]

@aarongable - thanks for pushing the OU limit change! Unless you have any further concern, I'd like to request your changes get merged into cabforum:profiles by @barrini or @vanbroup (SCWG chairs) such that I can initiate a second "round" of public discussion.

CC: @CBonnell @timfromdigicert @dzacharo and @clintwilson for:

• awareness given participation in this Pull Request's discussions or position as ballot endorser
• any final comments on the proposed set of changes discussed in this PR

[aarongable]

I have to admit I've slightly lost the plot on the discussion regarding cross-signs between Root CAs vs cross-signs between any CAs. I believe additional changes to 7.1.2.2.3 may be necessary for everyone to be happy here. But I agree that I think the right thing to do here is merge this change, send the ballot for discussion again, and garner perspectives on that section as a blank slate.

[ryancdickson]

@aarongable - just submitted a PR to this branch in hopes of clarifying the expectations re: cross-certificate EKU. I think this meets the intended goal of the earlier discussions in this thread (while also improving specificity re: the existing requirements defined in 1.8.6).

If you can merge in, I will move forward with:

• getting all of the changes covered in this PR into the main Pull Request
• sharing the updated ballot version with the SCWG.

I'm assuming we'll need at least one more round of discussion (necessitated by merging in SC-61 and/or the recent discussion re: pre-certs) - but am hopeful we won't go beyond that.

[ryancdickson]

@barrini or @vanbroup - can you please approve this Pull Request from @aarongable's local branch into cabforum:profiles such that we can continue discussion in the SCWG email distribution?

[we cannot continue without approval from servercert-chairs]

Thanks for your consideration!

[vanbroup]

@ryancdickson Kiran Tummala is the vice chairman of the server SCWG, as the vice chairman of the forum I can't approve this, sorry.

[ryancdickson]

My mistake @vanbroup, sorry about that! I'll follow-up with Kiran out of band (can't seem to find his GitHub handle).

[XolphinMartijn]

My mistake @vanbroup, sorry about that! I'll follow-up with Kiran out of band (can't seem to find his GitHub handle).

Looking at the Github Teams setup (which I believe the codeowners file uses), Kiran is not added there yet, so @barrini is needed for this one. We should get Kiran added there however

[aarongable]

Thanks for the approvals! I don't appear to have permission to merge; @ryancdickson do you have that ability?

[ryancdickson]

@aarongable - alas, I do not.

@barrini - can I please bother you for your help here, too? [Thank you!]

[barrini]

Done De: Ryan Dickson ***@***.***> Enviado el: jueves, 16 de febrero de 2023 21:41 Para: cabforum/servercert ***@***.***> CC: Inigo Barreira ***@***.***>; Mention ***@***.***> Asunto: Re: [cabforum/servercert] SC-062 Profiles: Address various editorial and content nits (PR #418) CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. @aarongable <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co m%2Faarongable&data=05%7C01%7Cinigo.barreira%40sectigo.com%7Cc2ebfc9b8c32460 f770e08db105e1bc8%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C6381217686187 26360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nfvYoLBvcupH6q7n5ktwnh6UyQHXTbQWt Nu%2BH8CglT4%3D&reserved=0> - alas, I do not. @barrini <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co m%2Fbarrini&data=05%7C01%7Cinigo.barreira%40sectigo.com%7Cc2ebfc9b8c32460f77 0e08db105e1bc8%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C6381217686187263 60%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha WwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DlsZooahXrCTThvOKjqNTwdmqzMM%2Bw1ymX b42vIeBX0%3D&reserved=0> - can I please bother you for your help here, too? [Thank you!] - Reply to this email directly, view it on GitHub <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co m%2Fcabforum%2Fservercert%2Fpull%2F418%23issuecomment-1433687690&data=05%7C0 1%7Cinigo.barreira%40sectigo.com%7Cc2ebfc9b8c32460f770e08db105e1bc8%7C0e9c48 946caa465d96604b6968b49fb7%7C0%7C0%7C638121768618726360%7CUnknown%7CTWFpbGZs b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 0%7C%7C%7C&sdata=nAKM2H1WnSbnIE2G7Qr0NP%2F9K%2BlFl4dSWmiL4zTiDG0%3D&reserved =0> , or unsubscribe <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co m%2Fnotifications%2Funsubscribe-auth%2FAWFQXOJA6AT3EDGFWNLDCT3WX2GFTANCNFSM6 AAAAAAUOLYJYU&data=05%7C01%7Cinigo.barreira%40sectigo.com%7Cc2ebfc9b8c32460f 770e08db105e1bc8%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C63812176861872 6360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CXinFRKbckGiW%2FX7f9BMsvXGfC4X3hds DgTAHN12uLA%3D&reserved=0> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AWFQXOKWA5SWG3J6I45W5R3WX2GFTA5CNFS M6AAAAAAUOLYJYWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTS VORLIU.gif> Message ID: ***@***.*** ***@***.***> >