SC-062 Profiles: Address various editorial and content nits #418

aarongable · 2023-02-02T00:14:50Z

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 · 2023-02-02T00:22:37Z

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 · 2023-02-03T12:49:47Z

docs/BR.md

@@ -309,7 +309,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S

 **Country**: Either a member of the United Nations OR a geographic region recognized as a Sovereign State by at least two UN member nations.

-**Cross-Certified Subordinate CA Certificate**: A certificate that is used to establish a trust relationship between two Root CAs.
+**Cross-Certified Subordinate CA Certificate**: A certificate that is used to establish a trust relationship between two CAs.


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.

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.

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.

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.

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?

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.

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.”

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

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

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.

docs/BR.md

CBonnell · 2023-02-03T19:43:44Z

docs/BR.md

@@ -309,7 +309,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S

 **Country**: Either a member of the United Nations OR a geographic region recognized as a Sovereign State by at least two UN member nations.

-**Cross-Certified Subordinate CA Certificate**: A certificate that is used to establish a trust relationship between two Root CAs.
+**Cross-Certified Subordinate CA Certificate**: A certificate that is used to establish a trust relationship between two CAs.


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

docs/BR.md

Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com>

docs/BR.md

[RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#:~:text=ub%2Dorganizational%2Dunit%2Dname%20INTEGER%20%3A%3A%3D%2064) defines 64 characters as the upper bound for ub-organizational-unit-name.

Fix upper bound for organizational-unit-name to match RFC 5280.

ryancdickson · 2023-02-14T17:37:58Z

@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 · 2023-02-15T01:40:19Z

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 · 2023-02-15T18:48:15Z

@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 · 2023-02-15T19:06:46Z

@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 · 2023-02-15T19:10:21Z

@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 · 2023-02-15T19:12:43Z

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

XolphinMartijn · 2023-02-15T19:22:23Z

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 · 2023-02-16T18:23:17Z

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

ryancdickson · 2023-02-16T20:40:45Z

@aarongable - alas, I do not.

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

barrini · 2023-02-17T11:20:32Z

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: ***@***.*** ***@***.***> >

* Profiles WIP * Clarify AIA based on 2021-06-12 call AIA allows multiple methods, and multiple instances of each method. However, client implementations use the ordering to indicate priority, as per RFC 5280, so clarify the requirements for multiple AccessDescriptions with the same accessMethod. * Address basicConstraints for OCSP Responder feedback Rather than make basicConstraints MUST, make it a MAY, to allow omission (plus v3) or presence (but empty) to indicate that it is not a CA certificate. * Address cRLDistributionPoints As captured on https://archive.cabforum.org/pipermail/validation/2021-July/001675.html provide better guidance for the encoding of cRLDistributionPoints and the permitted protocols. * Fix broken link and better clarify WIP sections * Clarify OCSP and other EKUs Non-TLS CAs MUST NOT include id-kp-OCSPSigning, since this would potentially make them OCSP signers for the issuing CA. Similarly, with respect to non-TLS CAs, it's fine (and useful!) to use other EKUs, so this is a MAY (or possibly SHOULD), not a SHOULD NOT. * Remove stale FIXME regarding serial numbers * Introduce Precertificate Signing CA Profile A Precertificate Signing CA, ontologically, a type of Technically Constrained Non-TLS Sub-CA, by virtue of the Extended Key Usage. To avoid ambiguity, this introduces a profile specific for Precert Signing CAs that make it clear that the Precert Signing EKU MUST be the only EKU present, to avoid a situation similar to that seen with OCSP responders. RFC 6962 is somewhat fast and loose with respect to whether or not "CA:true" is required in the profile for these, but in practice, implementations of logs, and existing CAs, do expect CA:true. Although not meant to be a normative change from the existing practices and consequences of existing requirements, it does make explicit that such CAs MUST only sign Precertificates; although this is less critical given the EKU constraint (to being a singular EKU), it represents a defense in depth approach consistent with existing practice. * Align postalCode/streetAddress hierarchy As pointed out by DigiCert, postal code represents a greater enclosing area than the street address, and thus hierarchically should appear first. * Fix nameConstraints for TLS subCAs They were accidentally a MUST, when they should have been a MAY. Bad copy/paste. * Bump OCSP placeholder dates for cert policies Move the effective date to 6 months from now; will likely continue to move as we finalize things, but offers a placeholder to handling effective dates. * Make cRLDP MUST NOT for OCSP Responders As pointed out by Corey, an id-pkix-ocsp-nocheck should be expected to disable all revocation checking (not just recursive OCSP revocation checking), so it makes sense to MUST NOT the cRLDP for the OCSP Responder, since we MUST nocheck. * Fix typo -> MMAY to MAY * Precertificates and Precertificate Signing CAs This introduces the notion of Precertificates and Precertificate Signing CAs as part of the Profiles, and captures the existing requirements from RFC 6962. It defines a Precertificate as based on a transformation of an existing Certificate conforming to one of the profiles, as opposed to attempting to define variants for every version or how to construct a Precertificate for a given profile. This attempts to similarly capture that, for purposes of compliance, a Precertificate is treated as if there is an equivalent Certificate, by reflecting that Precertificates need to match a Certificate based on the transformations defined, and that the Certificates need to match the profiles defined. * Address validity periods This attempts to clarify when/how backdating is allowed, particularly since it may affect path building. It gives a generous period for CA backdating when the distinguishedName remains the same, but may be imperfect if the keys are changing. * Address the "any other value" situations with 7.1.2.4 language This adopts the language from 7.1.2.4 to the various extensibility points, by trying to explicitly clarify as appropriate as to what is permitted. * Fix the certificatePolicies mismatched highlighted by Corey * Formatting and plurality fixup * Change SHOULD NOT to NOT RECOMMENDED While RFC 2119 establishes that these two phrases are semantically equivalent, it's been suggested that this may resolve some anxiety around misinterpretations of SHOULD NOT as SHALL NOT, particularly by auditors. By changing this to NOT RECOMMENDED, the same guidance is preserved, but it hopefully makes it more palatable to CAs. See https://github.com/sleevi/cabforum-docs/pull/36/files#r856429830 for related discussion. * Clarify subject name rules & add effective date This restructures the naming rules to try to clarify: - That technically constrained non-TLS sub-CAs are in-scope, but the certificates they issue are not - That the rules about byte-for-byte apply for all certificates in scope - That the requirements for the ordering and sequencing of names is a forward-dated requirement. Although it can be argued that some of these are existing requirements, avoid any messiness by structuring it holistically. - Adds a note to 7.1.4 to call out that 7.1.2.2.1 provides an exception - State the exception in 7.1.2.2.1 both normatively and informatively, to try and avoid misinterpretation. This was based on Corey's feedback in https://github.com/sleevi/cabforum-docs/pull/36/files#r689880007 * Remove dnsSRV and cleanup otherName handling This removes the (buggy) description of DNS SRV and leaves it overall as a SHOULD NOT and in scope of the (existing) 7.1.4.2 requirements. It also fixes up a typo (extension OID -> type-id) * Formatting fix * Move the Non-TLS EKU requirement into the Non-TLS profile Originally it was part of the common fields, when there were multiple variations of non-TLS CAs. However, as there is only a single reference to this section, fold it in to the non-TLS profile. This hopefully makes it clearer about the EKU requirements for non-TLS CAs (being what defines something as non-TLS), and reduces some confusion around non-TLS and TLS common sections. * Redo Certificate Policies for Non-TLS CAs The existing language was buggy, in that a link target was updated, but not the section heading. However, it was further buggy due to the interactions between Affiliated and Non-Affiliated CAs. This overhauls it in line with the November and F2F discussions; unlike many of the other extensions in this section (which are dictated by RFC 5280 as being mandatory for certain situations), certificatePolicies is not, so this is demoted to a MAY. However, the language from RFC 5280 does set out some guidance - such as not recommending that a policyQualifier be present - and so that requirement is preserved, under the argument that a non-TLS CA should still align with RFC 5280 if issued under a BR CA. This does *remove* an existing BR requirement, namely those inherited from Section 7.1.6.3, but since that seemed to align with the intent of the SCWG, this should be a positive change. * Make PolicyIdentifier ordering optional This makes the requirement for the Reserved Policy Identifier to be the first policyIdentifier optional, while explaining with a note the basis for that logic. To avoid confusion, it makes it clear that only one instance of a Reserved Policy Identifier may be present (e.g. can't be simultaneously OV and EV) * Indicate a max for serial numbers This incorporates Corey's https://github.com/sleevi/cabforum-docs/pull/39/commits/04c55a4cdf2f6ea068bd1f743a83b60def34dcae * Try to address the SKI uniqueness The approach to SKI uniqueness was flagged as ambigous, and two options were presented: - Option 1, mandate the SKI generation algorithm - Option 2, clarify that it's only unique "for the CA" Option 2 still has security risks with respect to denial of service, but CAs were unsure about when Option 1 would b eimplementable (e.g. if mandating SHA-2, CA software that uses SHA-1 would need to be updated). For now, this goes with Option 2, although a mandatory algorithm would resolve the issues wholesale. This is adapted from Corey Bonnell's https://github.com/sleevi/cabforum-docs/pull/39/commits/41cb3063b41af69615bba5410279396994d2ebc0 * Allow backdating up to 48 hours This adopts a 48 hour window, as proposed in https://github.com/sleevi/cabforum-docs/pull/39/commits/816ad7aa79cbfc1315561590d89ed7a9fd076b97 * Naming Cleanup This moves the metadata prohibition and domain name prohibition from applying to all certificates to only applying to Subscriber certificates (and in particular, to IV/OV/EV). This also corrects the organizationalUnit name to reflect SC47v2. * Harmonize effective dates to 2022-11-01 This only affects the certificatePolicies for OCSP Responders and the naming rules (for all certificates), but shifts to a harmonized date. * Formatting & Section Heading fixes This fixes a few unnumbered sections (around validity periods) and adjusts the formatting for several tables to better accomodate the text. * OrganizationalUnitName fixups Fixup the OU field * Remove stale TODO/TBDs * Fix a bug in non-TLS technically constrained CAs For non-TLS CAs, don't allow them to assert the BR's CP OIDs, as the certificates will not be BR compliant. * CT Cleanups In order for the precertificate signing CA to be considered technically constrained, restrict its EKU to only permitting it to issue precertificates. Additionally, add a cross-reference and tweak a MAY to a may, as the paragraph that follows the MAY contains the actual normative requirement, and this is just an informative explainer. * Remove rfc822Name from TLS technically constrained CAs rfc822Name is allowed, and described, in 7.1.2.10.9, as its a translation of the requirements of 3.2.2.4/3.2.2.5/7.1.2.4 of the existing BRs, and there are some CA profiles that allow non-TLS EKUs to be present (for ex, cross-certification). For technically constrained TLS sub-CAs, it was originally present because of Mozilla Root Store Policy, Section 1.1, which requires out-of-scope CAs to constrain on that name type. However, since a TCSC TLS CA MUST NOT include EKUs other than serverAuth & clientAuth, it was seen as unnecessary to even allow rfc822Name. * Clarify Precert language This clarifies the language around precerts by: * harmonizing on 'corresponding Certificate' instead of 'equivalent Certificate' * changing 'byte-for-byte equivalent' to 'byte-for-byte identical' to avoid any ambiguity * Rewording the AKI section when using a Precert Signing CA, to avoid stating the same requirement several ways that might be read as giving conflicting or different guidance, and RECOMMENDING/SHOULD harmonizing on the AKI containing the Precert Signing CA's SKI, as the Log is expected to transform and substitute (and all observed logs appear to do so). * Redo Certificate Policies This reworks the presentation and format of the certificatePolicies extensions, better aligning to the BRs, and hopefully providing sufficient clarity: Relaxations: - Reserved Policy OID is * no longer* required to be first, but is RECOMMENDED (SHOULD). - The separation of "Affiliated" and "Unaffiliated" for certificate policies is removed. This was introduced for Cross-Certified Sub-CAs, but resulted in some ambiguity about what happens when a Technically Constrained (non-TLS or nameConstraints) Sub-CA is operated by a non-Affiliated entity. The requirements around Affiliation are now folded into a common section, rather than being two sections. - Although not permitted by the current BRs, the cPSuri is now explicitly allowed for all certificate policies (_including_ for anyPolicy). - anyPolicy is now explicitly permitted (but NOT RECOMMENDED) for OCSP Responders - Reserved CABF OIDs are now explicitly permitted (but NOT RECOMMENDED) for OCSP Responders. Clarifications: - A note is added to the OCSP Responder section explaining that because CPs limit the validity and purposes of a certificate, it becomes possible to create an "invalid" responder that clients will reject (and thus also reject responses), and that this is part of the reason for forbidding. - For TLS certificates, the requirements for CPs for sub-CAs versus leaf certificates had a slightly different wording: whether a given CP needed to be documented by the CA (e.g. could be any policy, including a reserved CP or anyPolicy) or needed to be _defined_ and documented by the CA (i.e. must be from the CA's own OID arc). This harmonizes the language for TLS ("defined by"), while still leaving a fairly large carveout for non-TLS ("documented"). * Changes to Key Usage values for Subscriber Certificates (#376) Changing dataEncipherment for RSA and KeyAgreement for ECC to not recommended. * Definitions Update - Pending Prohibition (#388) * Add single all-encompassing effective date (#381) * Add single all-encompassing effective date * Integrate discussion from 2022-08-25 VSC call Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Add specification for EV attributes (#391) Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update to allow multiple instances of subject attributes (#392) * Update to allow multiple instances of subject attributes To allow for multiple instances of the domainContact attributes until we can address at an upcoming ballot. * Specific exceptions for attributes with multiple instances Allow multiple instances of the same attribute for `streetAddress` and `domainComponent`. For the latter, language from [ballot 102](https://cabforum.org/2013/05/31/ballot-102-br-9-2-3-domaincomponent/) was used. * Correct IV streetAddress multiple instances For consistency allow multiple instances for the `streetAddress` attribute in IV Certificates. * Update docs/BR.md Improved language for the domainComponent Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> * Add order and encoding requirement for DC attribute (#395) Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Clarify OUs in CA Certificates (#398) * Clarify that OUs are not allowed for CA Certificates described in section 7.1.2.3 per conversation in https://lists.cabforum.org/pipermail/validation/2022-October/001812.html. Added an effective date of 2022-12-12 which can be updated as needed. * Fix typo with quotes * Update based on F2F 57 - Removal of OU validation rules prior to 2022-12-12 because it includes non-TLS Issuing CAs - Clarification that the "MUST NOT" for OUs after 2022-12-12 also applies to Root CA Certificates and TLS Subordinate CA Certificates * fix effective date * Fix references and adding the two types of TLS CAs * Improve language around OUs in CA Certificates Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> * Capitalize "CA certificates" for consistency * Fix typo Fix typo based on https://github.com/cabforum/servercert/pull/398#discussion_r1013037979 Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> * Minor fixes and cleanups (#399) * Add order and encoding requirement for DC attribute * Remove overly specific Cross-cert requirement; fix serialNumber encoding * Clarify NC exclusion * Remove "Domain Name or IP Address" validation requirement for now Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Integrate newer ballots (#406) * Update README (#294) Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Adjust the workflow file to build the actions (#296) This addresses a few requests that recently came up from the certificate profiles work: - Remove the explicit retention period (of 21 days) to allow the GitHub default of 90 days. - Change the generated ZIP file from being "BR.md-hash" to being "BR-hash". - Allow manually invoking the workflow (via workflow_dispatch), in the event folks want to re-run for a particular branch (e.g. profiles) - Attempt to resolve the "non-deterministic redline" noted by Jos. When a given commit is on cabforum/servercert, it may be both a commit (to a branch) and part of a pull request (to main). We want the pull request redline to be against main, while the commit redline to be against the previous commit. Because both jobs run, and both upload the same file name, this results in a non-deterministic clobbering, where the commit-redline may clobber the pr-redline. This changes the generated zip file to be "file-hash-event_type", so that it will generate redlines for both PRs and commits and attach both. * SC47 Sunset subject:organizationalUnitName (#282) (#290) * SC47 Sunset subject:organizationalUnitName (#282) * Deprecation of subject:organizationalUnitName * Update language to avoid confusion on the effective date This version updates SC47 to state "issued on or after September 1, 2022" and makes the EV Guidelines reference the BRs as suggested by Ryan Sleevi from Google. Co-authored-by: Paul van Brouwershaven <vanbroup@users.noreply.github.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * SC47 datefix (#298) * Update dates table * Update EVG.md Add SC47 reference to relevant dates table * Fixup section number in prior commit Co-authored-by: Jos Purvis <jopurvis@cisco.com> Co-authored-by: Wayne Thayer <wthayer@gmail.com> * SC48 - Domain Name and IP Address Encoding (#285) (#302) * SC48 - Domain Name and IP Address Encoding (#285) * First pass * Add more RFC references, some wordsmithing * Another few fixes * Switch to use "LDH Labels" * Propose concrete effective date * Clarification about root zone trailing dot * Replace "label" with "Domain Label" throughout (#1) Replace "label" with "Domain Label" and "domain name" with "Domain Name" throughout Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos <castillar@melete.org> * Wrap xn-- to prevent ligaturization * SC48 - Domain Name and IP Address Encoding (#285) * First pass * Add more RFC references, some wordsmithing * Another few fixes * Switch to use "LDH Labels" * Propose concrete effective date * Clarification about root zone trailing dot * Replace "label" with "Domain Label" throughout (#1) Replace "label" with "Domain Label" and "domain name" with "Domain Name" throughout Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos <castillar@melete.org> * Wrap xn-- to prevent ligaturization * Update dates and version numbers Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC50 - Remove the requirements of 4.1.1 (#328) * SC50 - Remove the requirements of 4.1.1 (#323) * Bump cairosvg from 1.0.20 to 2.5.1 Bumps [cairosvg](https://github.com/Kozea/CairoSVG) from 1.0.20 to 2.5.1. - [Release notes](https://github.com/Kozea/CairoSVG/releases) - [Changelog](https://github.com/Kozea/CairoSVG/blob/master/NEWS.rst) - [Commits](https://github.com/Kozea/CairoSVG/compare/1.0.20...2.5.1) Signed-off-by: dependabot[bot] <support@github.com> * Bump kramdown from 2.3.0 to 2.3.1 Bumps [kramdown](https://github.com/gettalong/kramdown) from 2.3.0 to 2.3.1. - [Release notes](https://github.com/gettalong/kramdown/releases) - [Changelog](https://github.com/gettalong/kramdown/blob/master/doc/news.page) - [Commits](https://github.com/gettalong/kramdown/commits) Signed-off-by: dependabot[bot] <support@github.com> * Remove 4.1.1; persist compromised keys in 6.1.1.3 Remove section 4.1.1 from the BRs Explicitly require persistent access to compromised keys * Rebase based on upstream/main * Move System requirement to 6.1.1.3 * Add 4.1.1 as blank * Remove capitalization from 6.1.1.3 where terms are not defined * Re-add 'No stipulation.' to 4.1.1 * Remove change to 6.1.1.3 Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> * Update version and date table Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC53: Sunset SHA-1 for OCSP signing (#330) (#338) * Sunset SHA-1 for OCSP signing (#330) * Sunset SHA-1 OCSP signing * Clarify necessity of both items * Standardize date format, fix year in effective date table Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update version, table, and date Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Bump actions/checkout from 2 to 3 (#342) Bumps [actions/checkout](https://github.com/actions/checkout) from 2 to 3. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](https://github.com/actions/checkout/compare/v2...v3) --- updated-dependencies: - dependency-name: actions/checkout dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Ballot SC51: Reduce and Clarify Log and Records Archival Retention Requirements (#347) * Ballot SC51: Reduce and Clarify Audit Log and Records Archival Retention Requirements (#336) * Bump cairosvg from 1.0.20 to 2.5.1 Bumps [cairosvg](https://github.com/Kozea/CairoSVG) from 1.0.20 to 2.5.1. - [Release notes](https://github.com/Kozea/CairoSVG/releases) - [Changelog](https://github.com/Kozea/CairoSVG/blob/master/NEWS.rst) - [Commits](https://github.com/Kozea/CairoSVG/compare/1.0.20...2.5.1) Signed-off-by: dependabot[bot] <support@github.com> * Bump kramdown from 2.3.0 to 2.3.1 Bumps [kramdown](https://github.com/gettalong/kramdown) from 2.3.0 to 2.3.1. - [Release notes](https://github.com/gettalong/kramdown/releases) - [Changelog](https://github.com/gettalong/kramdown/blob/master/doc/news.page) - [Commits](https://github.com/gettalong/kramdown/commits) Signed-off-by: dependabot[bot] <support@github.com> * Restructure parts of 5.4.x and 5.5.x * Use 'events' consistently in 5.4.1 * Forgot to remove "revocation" as condition for start of retention period of Subscriber Certificates. * Introduce possessive in 5.4.1 and 5.5.1 to better deliniate responsiblities of CAs using DTPs * Remove WIP title; * re-order list in 5.5.2; add 'or' clause to validation documentation archival list entry. * Incorporate feedback from Aaron and Dimitris in Servercert-wg Discussion Period Based on the feedback from Aaron here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003115.html) and here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003125.html), update 5.5.1 and 5.5.2. Based on the feedback from Dimitris here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003110.html), update 5.4.3 and 5.5.2. * Update link formatting in 5.4.1 The "Section" links throughout include the word "Section" in the link, except for in 5.4.1; this fixes that inconsistency. Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> * Update effective date and version number * Update ballot table in document * Fix date string Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC54: Onion Cleanup (#369) * SC-54: Onion cleanup (#348) # Voting Results The voting on ballot SC54 has completed, and the ballot has passed. Voting Results Certificate Issuers votes total, with no abstentions: 18 Yes votes: Amazon, Buypass, DigiCert, eMudhra, Entrust, GDCA, GlobalSign, GoDaddy, HARICA, Izenpe, JPRS, NAVER, OISTE, Sectigo, SwissSign, TrustCor, SecureTrust, Visa 0 No Votes 0 Abstentions Certificate Consumers 6 votes total, with no abstentions: 6 Yes votes: 360, Apple, Cisco, Google, Microsoft, Mozilla 0 No votes 0 Abstentions Bylaw Requirements 1. Bylaw 2.3(f) requires: · A "yes" vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was MET for Certificate Issuers and MET for Certificate Consumers. · At least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was MET. 2. Bylaw 2.3(g) requires that a ballot result only be considered valid when “more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 14, so the quorum was 15 for this ballot. This requirement was MET. This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues. —— # Commit History * Addresses #270 allowing method 3.2.2.4.20 for `.onion` domains. * Addresses #242 creating an exception for `.onion` domains, using existing language from the opening section of 3.2.2.4. * Addresses #241 removing the currently deprecated Domain validation method 3.2.2.4.6. * Addresses #240. Things are signed using private, not public keys. * Addresses #190, #191. According to https://github.com/cabforum/servercert/issues/191#issuecomment-827810409, effectively 2021-10-15 is when v2 stops working everywhere. We could proceed without an effective date, remove most of Appendix F in the EV Guidelines and point to Appendix B of the Baseline Requirements directly. No strong feelings either way. * This is a mitigation against a malicious CA but the Applicant ultimately creates the Nonce. We agreed with Corey and Wayne to propose the removal of the requirement for the CA to *confirm* entropy. * Update language to deprecate legacy Appendix F validation method with "immediate" effect, after the ballot clears IPR (30 days after voting). * remove double space * Remove EVG Appendix F, introduce Onion Domain Name term * A few more minor tweaks * Fix numbering * Update for easier read. * Revert "Update for easier read." This reverts commit 1bac785b2fd6a3fe0957434f9d13b13a47d4d19b. Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * SC-54: Onion cleanup (#348) # Voting Results The voting on ballot SC54 has completed, and the ballot has passed. Voting Results Certificate Issuers votes total, with no abstentions: 18 Yes votes: Amazon, Buypass, DigiCert, eMudhra, Entrust, GDCA, GlobalSign, GoDaddy, HARICA, Izenpe, JPRS, NAVER, OISTE, Sectigo, SwissSign, TrustCor, SecureTrust, Visa 0 No Votes 0 Abstentions Certificate Consumers 6 votes total, with no abstentions: 6 Yes votes: 360, Apple, Cisco, Google, Microsoft, Mozilla 0 No votes 0 Abstentions Bylaw Requirements 1. Bylaw 2.3(f) requires: · A "yes" vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was MET for Certificate Issuers and MET for Certificate Consumers. · At least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was MET. 2. Bylaw 2.3(g) requires that a ballot result only be considered valid when “more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 14, so the quorum was 15 for this ballot. This requirement was MET. This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues. —— # Commit History * Addresses #270 allowing method 3.2.2.4.20 for `.onion` domains. * Addresses #242 creating an exception for `.onion` domains, using existing language from the opening section of 3.2.2.4. * Addresses #241 removing the currently deprecated Domain validation method 3.2.2.4.6. * Addresses #240. Things are signed using private, not public keys. * Addresses #190, #191. According to https://github.com/cabforum/servercert/issues/191#issuecomment-827810409, effectively 2021-10-15 is when v2 stops working everywhere. We could proceed without an effective date, remove most of Appendix F in the EV Guidelines and point to Appendix B of the Baseline Requirements directly. No strong feelings either way. * This is a mitigation against a malicious CA but the Applicant ultimately creates the Nonce. We agreed with Corey and Wayne to propose the removal of the requirement for the CA to *confirm* entropy. * Update language to deprecate legacy Appendix F validation method with "immediate" effect, after the ballot clears IPR (30 days after voting). * remove double space * Remove EVG Appendix F, introduce Onion Domain Name term * A few more minor tweaks * Fix numbering * Update for easier read. * Revert "Update for easier read." This reverts commit 1bac785b2fd6a3fe0957434f9d13b13a47d4d19b. Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update version numbers and dates Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Integrate SC-48 CN requirements Co-authored-by: Jos <castillar@melete.org> Co-authored-by: Jos Purvis <jopurvis@cisco.com> Co-authored-by: Ryan Sleevi <sleevi@google.com> Co-authored-by: Paul van Brouwershaven <vanbroup@users.noreply.github.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Wayne Thayer <wthayer@gmail.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> * Integrate SC-56 and SC-58 (#409) * Update README (#294) Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Adjust the workflow file to build the actions (#296) This addresses a few requests that recently came up from the certificate profiles work: - Remove the explicit retention period (of 21 days) to allow the GitHub default of 90 days. - Change the generated ZIP file from being "BR.md-hash" to being "BR-hash". - Allow manually invoking the workflow (via workflow_dispatch), in the event folks want to re-run for a particular branch (e.g. profiles) - Attempt to resolve the "non-deterministic redline" noted by Jos. When a given commit is on cabforum/servercert, it may be both a commit (to a branch) and part of a pull request (to main). We want the pull request redline to be against main, while the commit redline to be against the previous commit. Because both jobs run, and both upload the same file name, this results in a non-deterministic clobbering, where the commit-redline may clobber the pr-redline. This changes the generated zip file to be "file-hash-event_type", so that it will generate redlines for both PRs and commits and attach both. * SC47 Sunset subject:organizationalUnitName (#282) (#290) * SC47 Sunset subject:organizationalUnitName (#282) * Deprecation of subject:organizationalUnitName * Update language to avoid confusion on the effective date This version updates SC47 to state "issued on or after September 1, 2022" and makes the EV Guidelines reference the BRs as suggested by Ryan Sleevi from Google. Co-authored-by: Paul van Brouwershaven <vanbroup@users.noreply.github.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * SC47 datefix (#298) * Update dates table * Update EVG.md Add SC47 reference to relevant dates table * Fixup section number in prior commit Co-authored-by: Jos Purvis <jopurvis@cisco.com> Co-authored-by: Wayne Thayer <wthayer@gmail.com> * SC48 - Domain Name and IP Address Encoding (#285) (#302) * SC48 - Domain Name and IP Address Encoding (#285) * First pass * Add more RFC references, some wordsmithing * Another few fixes * Switch to use "LDH Labels" * Propose concrete effective date * Clarification about root zone trailing dot * Replace "label" with "Domain Label" throughout (#1) Replace "label" with "Domain Label" and "domain name" with "Domain Name" throughout Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos <castillar@melete.org> * Wrap xn-- to prevent ligaturization * SC48 - Domain Name and IP Address Encoding (#285) * First pass * Add more RFC references, some wordsmithing * Another few fixes * Switch to use "LDH Labels" * Propose concrete effective date * Clarification about root zone trailing dot * Replace "label" with "Domain Label" throughout (#1) Replace "label" with "Domain Label" and "domain name" with "Domain Name" throughout Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos <castillar@melete.org> * Wrap xn-- to prevent ligaturization * Update dates and version numbers Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC50 - Remove the requirements of 4.1.1 (#328) * SC50 - Remove the requirements of 4.1.1 (#323) * Bump cairosvg from 1.0.20 to 2.5.1 Bumps [cairosvg](https://github.com/Kozea/CairoSVG) from 1.0.20 to 2.5.1. - [Release notes](https://github.com/Kozea/CairoSVG/releases) - [Changelog](https://github.com/Kozea/CairoSVG/blob/master/NEWS.rst) - [Commits](https://github.com/Kozea/CairoSVG/compare/1.0.20...2.5.1) Signed-off-by: dependabot[bot] <support@github.com> * Bump kramdown from 2.3.0 to 2.3.1 Bumps [kramdown](https://github.com/gettalong/kramdown) from 2.3.0 to 2.3.1. - [Release notes](https://github.com/gettalong/kramdown/releases) - [Changelog](https://github.com/gettalong/kramdown/blob/master/doc/news.page) - [Commits](https://github.com/gettalong/kramdown/commits) Signed-off-by: dependabot[bot] <support@github.com> * Remove 4.1.1; persist compromised keys in 6.1.1.3 Remove section 4.1.1 from the BRs Explicitly require persistent access to compromised keys * Rebase based on upstream/main * Move System requirement to 6.1.1.3 * Add 4.1.1 as blank * Remove capitalization from 6.1.1.3 where terms are not defined * Re-add 'No stipulation.' to 4.1.1 * Remove change to 6.1.1.3 Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> * Update version and date table Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC53: Sunset SHA-1 for OCSP signing (#330) (#338) * Sunset SHA-1 for OCSP signing (#330) * Sunset SHA-1 OCSP signing * Clarify necessity of both items * Standardize date format, fix year in effective date table Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update version, table, and date Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Bump actions/checkout from 2 to 3 (#342) Bumps [actions/checkout](https://github.com/actions/checkout) from 2 to 3. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](https://github.com/actions/checkout/compare/v2...v3) --- updated-dependencies: - dependency-name: actions/checkout dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Ballot SC51: Reduce and Clarify Log and Records Archival Retention Requirements (#347) * Ballot SC51: Reduce and Clarify Audit Log and Records Archival Retention Requirements (#336) * Bump cairosvg from 1.0.20 to 2.5.1 Bumps [cairosvg](https://github.com/Kozea/CairoSVG) from 1.0.20 to 2.5.1. - [Release notes](https://github.com/Kozea/CairoSVG/releases) - [Changelog](https://github.com/Kozea/CairoSVG/blob/master/NEWS.rst) - [Commits](https://github.com/Kozea/CairoSVG/compare/1.0.20...2.5.1) Signed-off-by: dependabot[bot] <support@github.com> * Bump kramdown from 2.3.0 to 2.3.1 Bumps [kramdown](https://github.com/gettalong/kramdown) from 2.3.0 to 2.3.1. - [Release notes](https://github.com/gettalong/kramdown/releases) - [Changelog](https://github.com/gettalong/kramdown/blob/master/doc/news.page) - [Commits](https://github.com/gettalong/kramdown/commits) Signed-off-by: dependabot[bot] <support@github.com> * Restructure parts of 5.4.x and 5.5.x * Use 'events' consistently in 5.4.1 * Forgot to remove "revocation" as condition for start of retention period of Subscriber Certificates. * Introduce possessive in 5.4.1 and 5.5.1 to better deliniate responsiblities of CAs using DTPs * Remove WIP title; * re-order list in 5.5.2; add 'or' clause to validation documentation archival list entry. * Incorporate feedback from Aaron and Dimitris in Servercert-wg Discussion Period Based on the feedback from Aaron here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003115.html) and here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003125.html), update 5.5.1 and 5.5.2. Based on the feedback from Dimitris here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003110.html), update 5.4.3 and 5.5.2. * Update link formatting in 5.4.1 The "Section" links throughout include the word "Section" in the link, except for in 5.4.1; this fixes that inconsistency. Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> * Update effective date and version number * Update ballot table in document * Fix date string Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC54: Onion Cleanup (#369) * SC-54: Onion cleanup (#348) # Voting Results The voting on ballot SC54 has completed, and the ballot has passed. Voting Results Certificate Issuers votes total, with no abstentions: 18 Yes votes: Amazon, Buypass, DigiCert, eMudhra, Entrust, GDCA, GlobalSign, GoDaddy, HARICA, Izenpe, JPRS, NAVER, OISTE, Sectigo, SwissSign, TrustCor, SecureTrust, Visa 0 No Votes 0 Abstentions Certificate Consumers 6 votes total, with no abstentions: 6 Yes votes: 360, Apple, Cisco, Google, Microsoft, Mozilla 0 No votes 0 Abstentions Bylaw Requirements 1. Bylaw 2.3(f) requires: · A "yes" vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was MET for Certificate Issuers and MET for Certificate Consumers. · At least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was MET. 2. Bylaw 2.3(g) requires that a ballot result only be considered valid when “more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 14, so the quorum was 15 for this ballot. This requirement was MET. This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues. —— # Commit History * Addresses #270 allowing method 3.2.2.4.20 for `.onion` domains. * Addresses #242 creating an exception for `.onion` domains, using existing language from the opening section of 3.2.2.4. * Addresses #241 removing the currently deprecated Domain validation method 3.2.2.4.6. * Addresses #240. Things are signed using private, not public keys. * Addresses #190, #191. According to https://github.com/cabforum/servercert/issues/191#issuecomment-827810409, effectively 2021-10-15 is when v2 stops working everywhere. We could proceed without an effective date, remove most of Appendix F in the EV Guidelines and point to Appendix B of the Baseline Requirements directly. No strong feelings either way. * This is a mitigation against a malicious CA but the Applicant ultimately creates the Nonce. We agreed with Corey and Wayne to propose the removal of the requirement for the CA to *confirm* entropy. * Update language to deprecate legacy Appendix F validation method with "immediate" effect, after the ballot clears IPR (30 days after voting). * remove double space * Remove EVG Appendix F, introduce Onion Domain Name term * A few more minor tweaks * Fix numbering * Update for easier read. * Revert "Update for easier read." This reverts commit 1bac785b2fd6a3fe0957434f9d13b13a47d4d19b. Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * SC-54: Onion cleanup (#348) # Voting Results The voting on ballot SC54 has completed, and the ballot has passed. Voting Results Certificate Issuers votes total, with no abstentions: 18 Yes votes: Amazon, Buypass, DigiCert, eMudhra, Entrust, GDCA, GlobalSign, GoDaddy, HARICA, Izenpe, JPRS, NAVER, OISTE, Sectigo, SwissSign, TrustCor, SecureTrust, Visa 0 No Votes 0 Abstentions Certificate Consumers 6 votes total, with no abstentions: 6 Yes votes: 360, Apple, Cisco, Google, Microsoft, Mozilla 0 No votes 0 Abstentions Bylaw Requirements 1. Bylaw 2.3(f) requires: · A "yes" vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was MET for Certificate Issuers and MET for Certificate Consumers. · At least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was MET. 2. Bylaw 2.3(g) requires that a ballot result only be considered valid when “more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 14, so the quorum was 15 for this ballot. This requirement was MET. This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues. —— # Commit History * Addresses #270 allowing method 3.2.2.4.20 for `.onion` domains. * Addresses #242 creating an exception for `.onion` domains, using existing language from the opening section of 3.2.2.4. * Addresses #241 removing the currently deprecated Domain validation method 3.2.2.4.6. * Addresses #240. Things are signed using private, not public keys. * Addresses #190, #191. According to https://github.com/cabforum/servercert/issues/191#issuecomment-827810409, effectively 2021-10-15 is when v2 stops working everywhere. We could proceed without an effective date, remove most of Appendix F in the EV Guidelines and point to Appendix B of the Baseline Requirements directly. No strong feelings either way. * This is a mitigation against a malicious CA but the Applicant ultimately creates the Nonce. We agreed with Corey and Wayne to propose the removal of the requirement for the CA to *confirm* entropy. * Update language to deprecate legacy Appendix F validation method with "immediate" effect, after the ballot clears IPR (30 days after voting). * remove double space * Remove EVG Appendix F, introduce Onion Domain Name term * A few more minor tweaks * Fix numbering * Update for easier read. * Revert "Update for easier read." This reverts commit 1bac785b2fd6a3fe0957434f9d13b13a47d4d19b. Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update version numbers and dates Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * SC-56: 2022 Cleanup (#401) * SC-56: 2022 Cleanup (#385) Ballot has passed; moving to SC56 branch for IPR * #340 * #339 * #333 * #318 * #315 * #312 * #309 * #275 * #344 * #345 * #378 * #380 * #287 * #300 * #259 * #284 * #277 * #311 * #310 * Remove historical effective dates * #196 * #251 * #212 * #386 * Grammatical improvement suggested by Wendy Brown * Remove text for retired methods * Switch to new tables tooling * Fix broken section references * Bump upload-artifact version * Linkify US denied persons/entities list URLs Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update effective dates and tables Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * SC-58: Require distributionPoint in sharded CRLs (#396) (#403) * SC-58: Require distributionPoint in sharded CRLs (#396) * SC-XX: Require distributionPoint in sharded CRLs The language in RFC 5280 regarding the interaction between the distributionPoint field of the Issuing Distribution Point CRL extension and the existence of sharded CRLs has led to significant debate on interpretation, and appears to contradict X.509. To protect against replacement attacks, make it explicitly clear that the Issuing Distribution Point extension and distributionPoint field are required for sharded or partitioned CRLs. * Remind readers that the IDP must be critical * Change effective date to Jan 15 * Change effective date in Section 1.2 table, too * Update BR.md Co-authored-by: Aaron Gable <aaron@letsencrypt.org> Co-authored-by: Jos <castillar@melete.org> Co-authored-by: Jos Purvis <jopurvis@cisco.com> Co-authored-by: Ryan Sleevi <sleevi@google.com> Co-authored-by: Paul van Brouwershaven <vanbroup@users.noreply.github.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Wayne Thayer <wthayer@gmail.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> Co-authored-by: Iñigo Barreira <92998585+barrini@users.noreply.github.com> Co-authored-by: Aaron Gable <aaron@letsencrypt.org> * This PR fixes issues in section 7.1.2.7.3 and 7.1.2.7.4. (#416) * Profiles extended effective date (#413) * Update BR.md * Update BR.md * Add policyQualifiers Note (#412) * Add policyQualifiers Note Added explanation of rationale for NOT RECOMMENDED to section 7.1.2.10.5 * Update docs/BR.md Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> * SC-062 Profiles: Address various editorial and content nits (#418) * Use unicode figure space for table indentation * Use unicode superscript for exponentiation * Fix surname_givenname footnote link * Use approx instead of e.g. for approximate years * Include profile name in subsection titles * Reduce table duplication in 7.1.2.2.3 * Explain criticality of Subscriber SAN in-line * Unify language in 7.1.2.7.12 * Unify language around NULL extension values * Simplify CRL Distribution Point tables * Cross-Certification establishes trust between any two CAs * Fix AuthorityInfoAccessSyntax name * More flexible Certificate Policy OID definitions * Close two precertificates with same serial loophole * fix basicConstraints empty value Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> * Fix upper bound for organizational-unit-name [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#:~:text=ub%2Dorganizational%2Dunit%2Dname%20INTEGER%20%3A%3A%3D%2064) defines 64 characters as the upper bound for ub-organizational-unit-name. * Fix typo: "committment" --> "commitment" (#2) * Clarify Cross-Certificate EKU Requirements (#3) --------- Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Ryan Dickson <ryan.dickson@gmail.com> * Fix broken links (#427) * Update BR.md * Update BR.md * Update BR.md * Update BR.md * Update BR.md * Update BR.md (#429) --------- Co-authored-by: Ryan Sleevi <rsleevi@chromium.org> Co-authored-by: AnetaWojtczak <104534364+AnetaWojtczak@users.noreply.github.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> Co-authored-by: Jos <castillar@melete.org> Co-authored-by: Jos Purvis <jopurvis@cisco.com> Co-authored-by: Ryan Sleevi <sleevi@google.com> Co-authored-by: Paul van Brouwershaven <vanbroup@users.noreply.github.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Wayne Thayer <wthayer@gmail.com> Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Iñigo Barreira <92998585+barrini@users.noreply.github.com> Co-authored-by: Aaron Gable <aaron@letsencrypt.org> Co-authored-by: Ryan Dickson <ryan.dickson@gmail.com>

aarongable added 14 commits February 1, 2023 15:21

Use unicode figure space for table indentation

1e59bd6

Use unicode superscript for exponentiation

a75c91c

Fix surname_givenname footnote link

4e31494

Use approx instead of e.g. for approximate years

4befbbe

Include profile name in subsection titles

8767d3d

Reduce table duplication in 7.1.2.2.3

df496f3

Explain criticality of Subscriber SAN in-line

c0774f2

Unify language in 7.1.2.7.12

623f4a4

Unify language around NULL extension values

28d1ac7

Simplify CRL Distribution Point tables

41351f5

Cross-Certification establishes trust between any two CAs

bf02890

Fix AuthorityInfoAccessSyntax name

d2bf9a2

More flexible Certificate Policy OID definitions

0a5fed1

Close two precertificates with same serial loophole

1ff7f27

aarongable requested a review from a team as a code owner February 2, 2023 00:14

aarongable changed the title ~~Address various editorial and content nits~~ SC-062 Profiles: Address various editorial and content nits Feb 2, 2023