[cabf_validation] Minutes of the Validation SC Call on April 23, 2020

[Wayne Thayer]

# Minutes from the Validation Subcommittee Meeting of 23 April 2020.

## Attendees:
Tim Hollebeek, Doug Beattie, Ben Wilson, Corey Bonnell, Dean Coclin,
Dimitris Zacharopoulos, Enrico Entschew, Bruce Morton, Joanna Fox, Andrea
Holland, Daniela Hood, Shelley Brewer, Wayne Thayer, Aneta
Wojtczak-Iwanicka, Niko Carpenter, Janet Hines, Li-Chun Chen, Rich Smith,
Robin Alden, Ryan Sleevi

## Agenda:
Information sources
Progress on skeleton for certificate profiles

The antitrust statement was read by Tim, and a minute taker was assigned.
Ryan is on deck to take minutes next time.

## Information Sources
Tim - lots of discussion on the list about the purpose of this exercise
Dean - DigiCert still support this work
Doug - Not against the ballot, but looking for a clear reason because it
will require CAs to do some work. It’s good to have some reasons. Not
averse to having a uniform list. Just want a paragraph of why it’s
important.
Ryan - there has been a spate of quality control issues in the past year
and one half where areas left to CA discretion ended up with inadequate
controls and resulting quality issues. There is no way to know from the
certificate what the quality of the data source was. We became aware of
this when following up with a CA where the serial numbers weren’t as
expected. Revealed that there is an element of CA discretion particularly
in relation to validation sources that has become a concern since this is
core to the value provided by EV. Would like to resolve QGIS concerns as
well but that’s a bigger issue. Trying to bring transparency to ensure that
we’re all on the same page and there is consistency between CAs.
Doug - not convinced that publishing data sources helps with data quality.
Things can still be misspelled. Even for serial numbers, publishing this
list might not help catch process errors.
Ryan - this list isn’t going to solve quality control issues in State, but
might solve jurisdiction of incorporation issues. They are areas where the
CA is left to address process and policies. Seeing things slip through in
other areas (“Some State”), which brought this to attention. We have no way
to determine if agency of registration/incorporation is correct. There is
no visibility to the agency used, so this is meant to bring transparency.
We could also place this info into certificates, but that’s a different
conversation.
Doug - right. You just said that data quality issues are orthogonal. So
this doesn’t help the data quality issues without some automation to detect
and correct errors.
Ryan - default state “Some State” is core-related. That caused a lack of
confidence, and this proposal helps with the lack of confidence. Without
the lack of confidence, this wouldn’t be as important. It doesn’t solve
those other issues, but it addresses a crisis of confidence in CAs data.
Doug - by having CAs disclose their sources
Ryan - No ability to detect and remediate quality issues in these fields.
This is a small piece of the big problem. A small constrained problem.
Expectation is not that we’re suddenly going to revoke millions of certs.
This will expose inconsistencies that we’ll need to discuss. If I see
Sweden, what are the registries I should go check for the serial number?
Wayne - this discussion helps to make the connection between the issue and
how this proposal helps to solve it. There is also the question of why
we’re focusing on agency of incorporation. The answer came from the last
F2F meeting - we’d like to have more info on all data sources (QGIS, QIIS),
but agency of incorporation is a narrower scoped problem to solve.
Ryan - Doug, are you interested in working together to get the explanation
of why into the ballot?
Doug - yes, that will help all the CAs understand the rationale of the
ballot and it’s place in a multi-step process.
Ryan - we’ve talked about this as a multi-step process. Should we be
documenting the roadmap? Would documenting the end goal be helpful?
Doug - yes. Then people who don’t agree with the end goal could disagree
with these steps.
Tim - An analogy to the validation sources work might be useful, where the
first step was to ask CAs how they were doing validations.

## Skeleton for Certificate Profiles
Tim - didn’t see anything on the list, didn’t have a chance to check the
spreadsheet.
Ryan - hasn’t been a lot in the doc. Doug and Trev commented. Had to lock
down to comment only due to unattributed changes. Should this ballot be
prescriptive or descriptive? Thinking is that the ballot should just
capture requirements as they exist. There has been conversation about what
should be changed, e.g. CN on roots is just a SHOULD. Can CAs have multiple
CRLDPs? Does that mean only one or at least one? Existing requirements and
this profile don’t have a way to capture order of subject fields, but X.509
specifies this. Spreadsheet it still not fully filled out fully, especially
for for subscriber certificates. Happy to allow specific folks to edit
(just put your username in a comment), or just feel free to comment.
Tim - Agree that expressing current requirements in a better format is a
good first step. But there are missing requirements (that’s what started
this discussion), and we should address those in the ballot.
Ryan - interested in making progress on Subject name issues independent of
this ballot. Using that as an example, those requirements are ambiguous and
we need to decide how to handle. CRLDP is another, and we may want to
express the less permissive interpretation in this ballot. But there are
other issues/concerns with the profiles that are not ambiguous (e.g. other
extensions on roots) that we don’t need to tackle here.
Tim - would be also good to track the list of ambiguities/concerns that we
chose not to tackle in this ballot
Ryan - we have that in the spreadsheet, tracking future ideas for changes
in column M
Tim - let’s get the URL to the spreadsheet into the minutes again:
https://wiki.cabforum.org/validation
Doug - do we need to worry about what format markup supports?
Ryan - it’s a concern, but haven’t dealt with it yet. CA’s CP/CPS are very
prescriptive. Have been playing with different approaches to present this
info, but haven’t spent time worrying about markdown formatting yet.
Planning to work with Jos on some other MD formatting issues, and tables
will be part of that.
Doug - we need to worry about the numbering. We should try to keep the
numbering the same so that external references aren’t broken.
Ryan - thinking that the table will just become the section. We also need
to worry about distinguished names and how they fit into the sections. More
concerned with fleshing out the spreadsheet at this point.
Tim - we haven’t resolved the issue of what a skeleton will look like. What
is the path to figuring that out?
Ryan - on the spreadsheet, want to flesh out all the profiles and play with
the format. Each sheet becomes a new section. Would like to get comfortable
with the requirements before moving to MD.
Tim - the sheet is useful for playing with the data, but what’s the path
forward?
Ryan - reach agreement on the data in the sheet, then move to a document
format.
Dimitris - is root sheet complete now?
Ryan - it’s ready for review. Subordinate still has some issues with
extensions that need to be fleshed out. Root can be compared with section
7.1.2.1.
Tim - with 10 mins left, doesn’t make sense to dive into the sheet.
Ryan - please add comments to the sheet.
Doug - does it really need to be locked down due to IPR concerns when we’re
just transcribing?
Tim - strongly support the need to be able to attribute contributions to
specific people.
Ryan - question is if the transcription is accurate. If not, who proposed
it?
Dimitris - Does it make sense to add a comment pointing to the section of
the BRs that describes it?
Ryan - not sure, not opposed. Should probably be at the end of the doc.
Helps with the review but it’s a lot of info.
Tim - it would help me.
Ryan - I’ll add a column N.

## Meeting Adjourned
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20200423/5ad38284/attachment.html>