[cabf_validation] Draft minutes of Validation call March 26, 2020

[Doug Beattie]

Attendees: Andrea Holland, Aneta Wojtczak-Iwanicka, Bruce Morton, Clint
Wilson, Corey Bonnell, Daniela Hood, Doug Beattie, Janet Hines, Joanna Fox,
Mike Reilly, Niko Carpenter, Shelley Brewer, Tim Hollebeek, Trev
Ponds-White, Vincent Lynch, Wayne Thayer, Wendy Brown

 

Antitrust Statement was read by Tim H.

 

Agenda: Review section 7.1 of the BRs (certificate profiles), Discuss how
review went, next steps

 

Review section 7 of the BRs: 

 

We started with a discussion about what extensions are permitted in Root
certificates.  Section 7.1.2.1 lists 4 extensions, so this taken by itself
looks to exclude the use of any other extensions.   Section "7.1.2.4 All
Certificates" permits other extensions to all types, so the rules for Roots
(and actually any type of certificate) needs to be computed by looking at
multiple sections.  

*	Should section 7.1.2.4 be moved to be first so you see the common
things first?
*	Should we re-org the entire section?
*	Section 7.1.4 includes subject details which applies to each of the
certificate types, but is not within the specific certificate profile
subsections, so that is also confusing and not clear
*	While Certificate policy should not be present in roots:  What
happens if you do include it?  Can you put in LDAP URLs?
*	7.1.2.1.2 (Root key usages) needs to be unambitious.  As it stands,
7.1.2.1.2 appears to specify exactly what can go in a root certificate , but
then 7.1.2.4, which applies to all certificates, says you can add more as
long as "the CA is aware of a reason for including the data in the
Certificate" 
*	There was general agreement that this organization is not clear nor
well specified and the entire section should be reorganized.

 

Ryan asked what a re-organized section would look like.

 

Wayne asked how would we indicate something is extensible in this model
Wayne?

 

Ryan: said we could list all extensions as rows and then the "last row"
could be "Other extensions" which is a pointer to a section that says others
may be present and defines the rules.  This approach could allow us to
define rules that, for example, permit known and/or private extensions for
EE, and SubCAs, but not for Roots (if we want to lock them down 100%).  We
could also profile the contents of the subject DN fields and extensions to
clearly define which options are required/optional/not permitted.

 

Given the consensus that section 7 is not well organized, the group decided
that a new approach should be defined and reviewed at our next meeting.  The
focus will be on the Root certificate profile since that appears to be the
one with the least fields/extensions, and then extend to other profiles
after an approach has been defined.

 

Google Docs is a good, easy way to collaborate on content while GitHub is
more difficult for some members to use.  

 

Wayne suggested using a Google Doc or Google sheet and Ryan proposed the use
of GitHub, at least as a basis for testing the limits of formatting and to
verify the approach we come up with can be supported in GitHub (which this
section will need eventually created in).

 

With that in mind, Ryan offered to make a table for the Root certificate
profile in markdown and that we'll use a Google Sheet to capture the content
that will eventually go into GitHub. 


We'll review progress during our next call.

 

 

Doug Beattie

Minute taker

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20200401/014f6031/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5701 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20200401/014f6031/attachment.p7s>