[cabf_validation] Validation subcommittee scope and certificate profiles

[Tim Hollebeek]

If no one else objects, I’m willing to accept that argument as to why it is in scope, at least for section 7.1.

 

On the subject of a subcommittee on Default Deny, I’ll note that the minutes you referenced unfortunately don’t cover Tuesday, which is when I believe the discussion occurred.  We really need to be better about making sure we have minutes for subcommittee days.

 

-Tim

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Tuesday, March 17, 2020 11:42 AM
To: Tim Hollebeek <tim.hollebeek at digicert.com>; CABforum3 <validation at cabforum.org>
Subject: Re: [cabf_validation] Validation subcommittee scope and certificate profiles

 

 

 

On Tue, Mar 17, 2020 at 11:29 AM Tim Hollebeek via Validation <validation at cabforum.org <mailto: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/20200319/f8a10307/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20200319/f8a10307/attachment-0001.p7s>