[Servercert-wg] Discussion Period Begins: Ballot SC-062: Certificate Profiles Update
Aaron Gable
aaron at letsencrypt.org
Thu Feb 2 00:16:26 UTC 2023
I have included proposed fixes for all of these items in a GitHub pull
request, if that is an easier forum for discussion on these points:
https://github.com/cabforum/servercert/pull/418
On Wed, Feb 1, 2023 at 3:02 PM Aaron Gable <aaron at letsencrypt.org> wrote:
> Hi Ryan,
>
> Thanks so much for continuing to push this forward. Apologies for not
> leaving these comments earlier; I totally could have noticed these if I was
> doing closer readings prior to the discussion period beginning. I'm also
> happy to leave these comments directly on GitHub for easier
> cross-referencing if you'd like to create a PR from the redline linked in
> the ballot.
>
> 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.
>
> Aaron
>
> On Tue, Jan 31, 2023 at 7:52 AM Ryan Dickson via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
>> **Correction on the discussion period date format below, sorry about
>> that**
>>
>>
>> Purpose of Ballot
>>
>> Over the past three years, members of the Server Certificate Working
>> Group Validation Subcommittee have collaborated on an update to the Baseline
>> Requirements for the Issuance and Management of Publicly-Trusted
>> Certificates focused on improving the clarity of Section 7
>> (“Certificate, CRL, and OCSP Profiles”).
>>
>> The update:
>>
>> 1.
>>
>> better aligns certificate content expectations across certificate
>> issuers and consumers,
>> 2.
>>
>> reduces the opportunity for confusion resulting from the absence of a
>> more precise certificate profile specification, and
>> 3.
>>
>> promotes more consistent and reliable implementations across the
>> ecosystem.
>>
>>
>> While most of the proposed updates focus on Section 7, changes were not
>> limited to only this section.
>>
>> Technical discussion related to the proposed changes, along with
>> high-level change summaries have been documented in:
>>
>> -
>>
>> open GitHub pull requests (originally here
>> <https://github.com/sleevi/cabforum-docs/pull/36>, and more recently
>> here <https://github.com/cabforum/servercert/pull/373>),
>> -
>>
>> several closed GitHub pull requests made against the “profiles
>> <https://github.com/cabforum/servercert/tree/profiles>” branch of the
>> servercert GitHub repository, and
>> -
>>
>> Validation Subcommittee meeting minutes (to include sessions held at
>> Face-to-Face meetings).
>>
>>
>> Due to a small number of changes proposed in the ballot that is otherwise
>> focused on clarifying existing requirements, an “all-encompassing”
>> effective date makes these changes normative beginning 2023-09-15.
>>
>> The following motion has been proposed by Ryan Dickson of Google and
>> endorsed by Clint Wilson of Apple and Dimitris Zacharopoulos of HARICA.
>>
>> — Motion Begins —
>>
>> This ballot modifies the “Baseline Requirements for the Issuance and
>> Management of Publicly-Trusted Certificates” (“Baseline Requirements”),
>> based on Version 1.8.6.
>>
>> MODIFY the Baseline Requirements as specified in the following Redline:
>> https://github.com/cabforum/servercert/compare/2c63814fa7f9f7c477c74a6bfbeb57e0fcc5dd5b..0689ba59dbad9f5d2a5269051e5e0d0d1a25f3f6
>>
>>
>> — Motion Ends —
>>
>> This ballot proposes a Final Maintenance Guideline. The procedure for
>> approval of this ballot is as follows:
>>
>> Discussion (7+ days)
>>
>> -
>>
>> Start time: 2023-*01-31* 15:00:00 UTC
>> -
>>
>> End time: Not before 2023-02-07 15:00:00 UTC
>>
>>
>> Vote for approval (7 days)
>>
>> -
>>
>> Start time: TBD
>> -
>>
>> End time: TBD
>>
>>
>> On Tue, Jan 31, 2023 at 10:01 AM Ryan Dickson via Servercert-wg <
>> servercert-wg at cabforum.org> wrote:
>>
>>> Purpose of Ballot
>>>
>>> Over the past three years, members of the Server Certificate Working
>>> Group Validation Subcommittee have collaborated on an update to the Baseline
>>> Requirements for the Issuance and Management of Publicly-Trusted
>>> Certificates focused on improving the clarity of Section 7
>>> (“Certificate, CRL, and OCSP Profiles”).
>>>
>>> The update:
>>>
>>> 1.
>>>
>>> better aligns certificate content expectations across certificate
>>> issuers and consumers,
>>> 2.
>>>
>>> reduces the opportunity for confusion resulting from the absence of
>>> a more precise certificate profile specification, and
>>> 3.
>>>
>>> promotes more consistent and reliable implementations across the
>>> ecosystem.
>>>
>>>
>>> While most of the proposed updates focus on Section 7, changes were not
>>> limited to only this section.
>>>
>>> Technical discussion related to the proposed changes, along with
>>> high-level change summaries have been documented in:
>>>
>>> -
>>>
>>> open GitHub pull requests (originally here
>>> <https://github.com/sleevi/cabforum-docs/pull/36>, and more recently
>>> here <https://github.com/cabforum/servercert/pull/373>),
>>> -
>>>
>>> several closed GitHub pull requests made against the “profiles
>>> <https://github.com/cabforum/servercert/tree/profiles>” branch of
>>> the servercert GitHub repository, and
>>> -
>>>
>>> Validation Subcommittee meeting minutes (to include sessions held at
>>> Face-to-Face meetings).
>>>
>>>
>>> Due to a small number of changes proposed in the ballot that is
>>> otherwise focused on clarifying existing requirements, an
>>> “all-encompassing” effective date makes these changes normative beginning
>>> 2023-09-15.
>>>
>>> The following motion has been proposed by Ryan Dickson of Google and
>>> endorsed by Clint Wilson of Apple and Dimitris Zacharopoulos of HARICA.
>>>
>>> — Motion Begins —
>>>
>>> This ballot modifies the “Baseline Requirements for the Issuance and
>>> Management of Publicly-Trusted Certificates” (“Baseline Requirements”),
>>> based on Version 1.8.6.
>>>
>>> MODIFY the Baseline Requirements as specified in the following Redline:
>>> https://github.com/cabforum/servercert/compare/2c63814fa7f9f7c477c74a6bfbeb57e0fcc5dd5b..0689ba59dbad9f5d2a5269051e5e0d0d1a25f3f6
>>>
>>>
>>> — Motion Ends —
>>>
>>> This ballot proposes a Final Maintenance Guideline. The procedure for
>>> approval of this ballot is as follows:
>>>
>>> Discussion (7+ days)
>>>
>>> -
>>>
>>> Start time: 2023-31-01 15:00:00 UTC
>>> -
>>>
>>> End time: Not before 2023-02-07 15:00:00 UTC
>>>
>>>
>>> Vote for approval (7 days)
>>>
>>> -
>>>
>>> Start time: TBD
>>> -
>>>
>>> End time: TBD
>>>
>>> _______________________________________________
>>> Servercert-wg mailing list
>>> Servercert-wg at cabforum.org
>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>>
>> _______________________________________________
>> Servercert-wg mailing list
>> Servercert-wg at cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230201/73c2d98f/attachment-0001.html>
More information about the Servercert-wg
mailing list