[cabf_validation] Draft Minutes for Validation Subcommittee Teleconference - November 5, 2020

[Ryan Sleevi]

# Attendees
Andrea Holland, Aneta Wojtczak, Ben Wilson, Bruce Morton, Christy Berghoff,
Clint Wilson, Corey Bonnell, Daniela Hood, Doug Beattie, Dimitris
Zacharopolous, Dean Coclin, Janet Hines, Johnny Reading, Michelle Coon,
Niko Carpenter, Paul van Brouwershaven, Rebecca Kelley, Rich Smith, Ryan
Sleevi, Shelly Brewer, Stephen Davidson, Thomas Zermeno, Tim Hollebeek,
Trevoli Ponds-White, Wayne Thayer

# Antitrust Statement
The Antitrust Statement was read by Tim.

# Agenda
  * Redirect improvements
  * OU Proposal
  * Format of Certificate Profiles

## Redirect Improvements
Niko described how the BRs refer to RFC 7231 for status codes for
redirects, but this overlooks 308, which is RFC 7238, which also seems like
it should be acceptable. Based on discussion on the list in the past, it
seemed like an approach of enumerating the desired redirects was the right
approach. Niko's proposal based on that narrowed down to 301, 302, 307, and
308 for 3.2.2.4.18 and 3.2.2.4.19 in domain validation.

Ryan indicated he hadn't read Niko's latest mail on the language, but
suspects that Google would be able to support in principle, since those
four codes do sound correct. Niko mentioned there hadn't been many comments
on the mail regarding the language.

Tim suspected there might be more comments on the language, but the best
path forward is to start working on a ballot, as folks may not read until
it's in voting.

## OU Proposal
Paul shared a risk register on the list, and had received feedback from
Ryan. He indicated he's looking for more feedback, and still continuing to
explore the contents of the draft.

## Format of Certificate Profiles
Stephen Davidson was invited to the call, given the potential overlap of
use case for the S/MIME Work Group. This topic was discussed at the F2F,
and the high level strategy sounds like there will be one table for each of
the different certificate types, so they can have their own independent
list of allowed/disallowed fields, just like there is presently in the
spreadsheet that was started.

When it comes to some of the complicated fields, like Subject DN, have
break out into sub-tables that capture the allowed forms, to avoid needing
to have a bunch of conditionality within the table or in the requirements.

Stephen indicated he was interested in understanding how the table approach
would work for different variants of certificate types. For example, in the
S/MIME case, you can have different groups of key usages involved. Tim
mentioned it doesn't show up as much in the TLS world, but if there were
multiple use cases and different profiles, split out the tables by use case
(e.g. by EKU) to address the different requirements, to keep it simple.

Corey suggested that some of the common fields in the subject DN might be
in the same table, such as countryName or locality, but that those RDNs
that change based on policy, such as organization name, might be in
different tables depending on the type. For example, if it's IV, put this
value in the O field, if it's OV, put this other value of the O field.

Ryan said the suggestion was that instead of having clusters of common
fields, that we'd group a table for the whole DN. For example, this is what
a DN looks like for an IV, this is what a DN looks like for an OV without a
recognized country (the 'XX' problem), this is what a DN looks like for OV
with a recognized country. Something somewhat similar to how we've done in
the sheet, with columns for the field, the attribute, and then a reference
to the section describing the validation for the attribute. The references
for a number of attributes will be similar, but for some situations (e.g.
IV w/o using givenName), fields might refer to a more specific section. The
idea being that we have a set of clear tables, and all DNs must be able to
be matched against exactly one of those tables, to avoid having to have
folks pick and choose "some from this table, a little from that table".

Corey was concerned about the possible duplication, if we changed the
validation rules for a field, we'd need to make sure to update all the
references, and it would introduce the potential to miss updating a field.
But he also acknowledged this may not change often and may not be in
practice.

Tim mentioned he's not normally a fan of duplication, but having the
information duplicated in this case makes sense, because it makes the
profiles flat, simple, and non-conditional. He suggested we might want a
worksheet to help remind folks to update relevant sections, particularly if
other WG copy the approach, but the benefits of the flat approach seem
worth it.

Dimitris raised a question about how we explore other attributes. Some
certificate profiles allow additional, arbitrary RDN attributes, and how
would that be represented? Ryan explained that just like we did with
3.2.2.4, we would add a row at the bottom of the tables that allowed
arbitrary attributes, and then a reference to the section describing the
(generic) validation requirements for these fields. If we then take an
approach like 3.2.2.4 of removing "any other method", we can add new rows
for the relevant certificate types detailing the additional DN fields that
are allowed and sections for how to validate them.

Tim asked what the next steps were? There was agreement that we just needed
to go heads down and make a draft to get discussion.

Ryan raised a matter of keyUsage tied to the subjectPublicKeyInfo, and
suggested that we might need to have a few small clusters, like we suggest
for distinguishedName/certificatePolicy, where we indicate in the profile
which fields are required, but leave their value to breakout tables (e.g.
RSA vs ECDSA). Tim agreed that sounded reasonable, and would be great if
folks could put together a strawman before the next call.

Corey asked which profile we should begin with. The validation WG
originally began with a root certificate, would we start there? Tim
suggested we might want to begin with the complicated case first to make
sure it works out. Ryan agreed that it makes sense to start with the
end-entity certificates, since we have many variants. Subordinates have
some interesting interactions with cross-signed certificates, so there are
some edges. Root Certificates should be the easiest, and should probably
last.

Wayne asked if we had a plan for making sure that this approach would work
in Markdown and how our documents are produced. Ryan mentioned that he
hadn't started this yet, as he's been focused on the GitHub migration. Ryan
has been working with Jos to enable some automation and cleanup of our
templates, mentioned at the F2F, so that we can have an easy edit/preview
cycle, including in members' forks. Tim asked what the timeline, and Ryan
mentioned that having the automation was the goal before the next call. At
the F2F, he mentioned there's one security issue he wants to make sure is
good. He also wanted to try to make this generic, for other WGs to be able
to use, but the focus first would be on the servercert repository. Tim
agreed this would be very useful, and suggested we begin this work in
Markdown to make sure it works.

Wayne pointed out that there's a few WYSIWYG Markdown table editors, and
wasn't sure if that made sense to use. Tim agreed that'd be useful, to
avoid editing Markdown on the calls themselves. Wayne didn't have a
specific recommendation for a tool, but there was agreement this would be
useful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201105/c7dee53b/attachment.html>