[Servercert-wg] Discussion Period Begins: Ballot SC-062: Certificate Profiles Update
Aaron Gable
aaron at letsencrypt.org
Wed Feb 1 23:02:00 UTC 2023
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/69525afe/attachment-0001.html>
More information about the Servercert-wg
mailing list