[Servercert-wg] Discussion Period Begins: Ballot SC-062: Certificate Profiles Update
Ryan Dickson
ryandickson at google.com
Fri Feb 3 20:18:14 UTC 2023
Hi Aaron,
Thanks for suggesting these changes (and for taking the time to create a PR
to incorporate them into the existing draft) - and thank you to those who
have participated in the resulting GitHub discussion
<https://github.com/cabforum/servercert/pull/418/files>.
Members should feel welcome to continue providing comments against the initial
redline version
<https://github.com/cabforum/servercert/compare/2c63814fa7f9f7c477c74a6bfbeb57e0fcc5dd5b..0689ba59dbad9f5d2a5269051e5e0d0d1a25f3f6>
or the changes proposed by Aaron
<https://github.com/cabforum/servercert/pull/418>. For the group's
convenience and to help with participant review, I annotated many of the
changes in #418 with the commentary included in Aaron's initial message.
The discussion period will continue beyond the initially proposed "Not
before" date of 2023-02-07 15:00:00 UTC. Once we have a "clean" updated
version with the initial set of comments adjudicated, I'll call for a
second discussion period to focus on the updated version.
Thank you all for the continued collaboration.
- Ryan
On Wed, Feb 1, 2023 at 7:16 PM Aaron Gable <aaron at letsencrypt.org> wrote:
> 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/20230203/c3b2de15/attachment-0001.html>
More information about the Servercert-wg
mailing list