<div dir="ltr"><div># Minutes from the Validation Subcommittee Meeting of 23 April 2020.</div><div><br></div>## Attendees:<br>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<br><div><br></div><div>## Agenda:</div>Information sources<br>Progress on skeleton for certificate profiles<br><br>The antitrust statement was read by Tim, and a minute taker was assigned. Ryan is on deck to take minutes next time.<br><br>## Information Sources<br>Tim - lots of discussion on the list about the purpose of this exercise<br>Dean - DigiCert still support this work<br>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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>Doug - by having CAs disclose their sources<br>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?<br>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.<br>Ryan - Doug, are you interested in working together to get the explanation of why into the ballot?<br>Doug - yes, that will help all the CAs understand the rationale of the ballot and it’s place in a multi-step process.<br>Ryan - we’ve talked about this as a multi-step process. Should we be documenting the roadmap? Would documenting the end goal be helpful?<br>Doug - yes. Then people who don’t agree with the end goal could disagree with these steps.<br>Tim - An analogy to the validation sources work might be useful, where the first step was to ask CAs how they were doing validations.<br><br>## Skeleton for Certificate Profiles<br>Tim - didn’t see anything on the list, didn’t have a chance to check the spreadsheet.<br>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.<br>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.<br>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.<br>Tim - would be also good to track the list of ambiguities/concerns that we chose not to tackle in this ballot<br>Ryan - we have that in the spreadsheet, tracking future ideas for changes in column M<br>Tim - let’s get the URL to the spreadsheet into the minutes again: <a href="https://wiki.cabforum.org/validation">https://wiki.cabforum.org/validation</a><br>Doug - do we need to worry about what format markup supports?<br>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.<br>Doug - we need to worry about the numbering. We should try to keep the numbering the same so that external references aren’t broken.<br>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.<br>Tim - we haven’t resolved the issue of what a skeleton will look like. What is the path to figuring that out?<br>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.<br>Tim - the sheet is useful for playing with the data, but what’s the path forward?<br>Ryan - reach agreement on the data in the sheet, then move to a document format.<br>Dimitris - is root sheet complete now?<br>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.<br>Tim - with 10 mins left, doesn’t make sense to dive into the sheet.<br>Ryan - please add comments to the sheet.<br>Doug - does it really need to be locked down due to IPR concerns when we’re just transcribing?<br>Tim - strongly support the need to be able to attribute contributions to specific people.<br>Ryan - question is if the transcription is accurate. If not, who proposed it?<br>Dimitris - Does it make sense to add a comment pointing to the section of the BRs that describes it?<br>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.<br>Tim - it would help me.<br>Ryan - I’ll add a column N.<br><br>## Meeting Adjourned</div>