[cabf_validation] Validation subcommittee scope and certificate profiles

[Ryan Sleevi]

On Tue, Mar 17, 2020 at 11:29 AM Tim Hollebeek via Validation <
validation at cabforum.org> wrote:

>
>
> During last week at the validation subcommittee meeting, we discussed
> going through section 7.1 (certificate profiles) on next week’s validation
> subcommittee call.  This is important work, but I have some concerns
> related to a concern I previously raised in Guangzhou: I’m not sure that
> certificate profiles are in scope for the validation subcommittee.  I would
> be interested to hear other people’s opinions, including how we should
> handle that problem.
>

As mentioned on the call, I don't share your skepticism, although I
appreciate your attentiveness to charters.

The Charter Scope should be obvious here as to why that is:
Scope: The scope of this Subcommittee is to address issues arising under
adopted CA/Browser Forum guidelines and requirements related to the
validation of certificate information and *the inclusion of information in
certificates*. The Subcommittee will consider all matters relating to the
validation and *inclusion of information in certificates* under adopted
CA/Browser Forum guidelines and requirements.

I've bolded the relevant section, but if it doesn't come through, this is
about the *inclusion of information in a certificate*, which is
fundamentally what a Certificate Profile is. If you disagree, it'd be
useful to understand why.

As a concrete datapoint, consider the discussion around the validation and
inclusion of Subject fields (
https://github.com/cabforum/documents/issues/154 ). As we've seen, the
structure of the BRs around the "validation and inclusion of information in
the Subject" has lead CAs to a myriad of interpretations, most prominently:
- They can include any field in the Subject of a Sub-CA certificate, with
no validation requirements
- They can include any field in the Subject of a Sub-CA certificate that is
permitted for End-Entity certificates, using the validation process
described therein
- They can include any field in the Subject of a Sub-CA certificate, but
those that are permitted for End-Entity must be validated the same way

In looking at how to resolve this, one of the challenges, and why I brought
this to the attention of the Validation WG, is that a naive take that tried
to preserve the existing structure would necessitate duplicating the
validation process textually within these fields. That's understandably not
the goal.

As described on the call, and I'll check that our minutes reflect, the
proposal is that Section 7.1 describes *how information is included in
certificates*, while we use section 3 to describe *how information is
validated within certificates*. This has obvious benefits to other fields,
such as the discussion around nameConstraints and Reserved IP addresses (
https://github.com/cabforum/documents/issues/160 ) , by having a consistent
process to describe the validation expectations for a validated field (e.g.
3.2.2.4 / 3.2.2.5), while having the Certificate Profile expressing how
information is included and when it is validated (e.g. permittedSubtrees)
vs when it may not be (e.g. excludedSubtrees)

I’ll note that the consensus in Guangzhou was to form a separate
> subcommittee to address that problem, but that doesn’t seem to have
> happened.
>

In general, statements like this are not helpful, without some reference to
where. For example, the minutes in
https://cabforum.org/2019/12/12/minutes-for-ca-browser-forum-f2f-meeting-48-guangzhou-5-7-november-2019/
only
have two instances of the word "profile", and don't seem to support your
statement here, as do all references for "subcommittee". For those of us
who attended remotely, it's useful to have the minutes to have context.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20200317/3aa0c973/attachment-0001.html>