<div dir="ltr"><div># Minutes from the Validation Subcommittee Meeting of 16 July 2020.</div><div><br></div>## Attendees:<br><div>Tim Hollebeek, Ryan Sleevi, Daniela Hood, Clint Wilson, Andrea Holland, Ben Wilson, Bruce Morton, Corey Bonnell, Enrico Entschew, Janet Hines, Joanna Fox, Johnny Reading, Julie Olson, Kirk Hall, Li-Chun CHen, Niko Carpenter, Robin Alden, Shelley Brewer, Trev, Wayne Thayer</div><div><br></div>## Agenda:<br>Look at the Trello board<br>Consider transitioning Trello to GitHub<br>Certificate profiles<br><br>The antitrust statement was read by Wayne, and a minute taker was assigned.<br><br>## Agenda review<br>Daniela asked to add a question about ballot SC30.<br>Tim - Go ahead now<br>Daniela - for Government Entities we can use EV section 6. For Business Entities we can validate via direct contact with the registration agency. These are normally one-off validations.<br>Ryan - sounds like for Business Entities the case is where you contact the registration agency directly?<br>Daniela - correct, we call them to validate documentation. It’s a jurisdiction that we wouldn’t normally use, so wouldn’t normally be disclosed. Sounds like the source should be disclosed before the cert is issued.<br>Ryan - correct for Business Entities. On Government Entities, for example, there was a question on which source to use. One CA cited an act of parliament, but upon later review found that later acts had invalidated it. Government entities don’t always have that. This ballot is focused on Business Entities where agency of registration or incorporation is used. Would be nice to have data for government entities, but that’s not required by SC30.<br>Daniela - that clarifies it<br>Tim - there is no clear line between what is a government agency and what isn’t. Something we might want to think about in the future.<br><br>## Trello board<br>Tim - (sharing Trello board, which is linked from the wiki) how do we want to do this? Go through all the cards?<br>Wayne - there aren’t that many, we should be able to review them all.<br>Tim - ‘Require DNSSEC validation for CAA records when the domain is DNSSEC enabled’.<br>Ryan - this helps distinguish malicious attacks from benign failures. This would require CAs to check DNSSEC if the domain has it enabled.<br>Tim - will we get to this soon? Since no one responded, remains in backlog.<br>Tim - ‘Improve CAA logging’ - not many requirements around what CAs must log. Remains in backlog<br>Tim - ‘Definition of Applicant is different for 3.2.2.4 that it is for the rest of the document’. This is interesting. Tim will work on this - moving to ‘on-deck’.<br>Ryan - there are considerations beyond 3.2.2.4. Worked with a CA that also provides hosting services - e.g. Google, Amazon, GoDaddy, Microsoft. There is inconsistency that makes this scenario challenging. Need to make sure Applicant/Subject/Subscriber terms are used consistently throughout the doc.<br>Tim - another case is a CA issuing a cert for its own website. Some language is problematic when Applicant and CA are the same. Key generation is an interesting issue.<br>Tim - ‘Independent subjects with independent SANS. X500 from Peter’. Not sure what this is.<br>Ryan - having a CDN as the named Subject of a cert with a bunch of unrelated domains in the SAN is the issue. E.g. ‘Cloudflare’ in the O field. Is that desirable?<br>Tim - not sure this is useful<br>Ryan - agree<br>Tim - moved this item to ‘closed’<br>Tim - ‘Define CAA extensions for validation methods’. Got hung up around how to specify methods. This is not a near term work item.<br>Ryan - agree, this requires a concrete proposal.<br>Tim - ‘Require domain validations to be performed from multiple network perspectives…’. This needs a concrete proposal.<br>Ryan - agree, the devil is in the details<br>Tim - ‘IP address DNS txt. Validation’. Propose we close this due to insufficient detail<br>Tim - Require validation method OIDs in certs Leave in backlog<br>Tim - ‘Workaround for DNS fragmentation attacks’. <br>Ryan - Workaround proposed by academic paper and implemented by Let’s Encrypt. Proposal was to add it to the BRs. Would prefer to see a normative requirement that requires a bunch of specification work.<br>Tim - leave in backlog<br>Tim - ‘Bygone SSL’. Tie cert validity to domain registration period.<br>Ryan - Wouldn’t want to lump this together with registration lifetimes. Bygone SSL is really domain reuse. Roots stores are looking at reducing information reuse period rather than tie to registration period.<br>Tim - high priority. Move to ‘in progress’.<br>Ryan - second priority after cert profiles for us<br>Tim - ‘Peter’s registrar challenge-response validation method’. Interesting, needs a champion to write a proposal.<br>Ryan - this is somewhat ameliorated by the newer DNS methods. Addresses case where whois data can’t be modified or isn’t public.<br>Trev - is this the same as method 12 that Dave Blunt was going to work on?<br>Ryan - yes<br>Tim - ‘Backdating notBefore'<br>Ryan - this fits into the profile work. Also, in SC31 (browser alignment), validity period is aligned with the RFC 5280 definition. This proposal was to clarify the relationship between notBefore and issuance time for end-entity certs. And probably OCSP responder certs.<br>Tim - in the validation requirements of the notBefore section of the profile.<br>Ryan - yes, a rule on what the contents can be.<br>Tim - ‘Delegating DNS to the CA’. Did the m.d.s.p. thread reach a conclusion?<br>Ryan - in order to make progress, need to sort out Applicant/Subscriber/Subject definitions, and need concrete proposals that we can use to reason about the security properties of the implementation, which is easy to get wrong. Also relates to CA protection of Subscriber accounts. This moves threat of DNS compromise from Subscriber to the CA. Need more discussion about what CA controls are needed.<br>Tim - Also related to granting CAs permission to use specific validation methods so Subscribers can opt-in. In backlog pending a concrete proposal.<br>Tim - ‘Validation requirements for .arpa domains’. Lots of sketchy stuff going on under .arpa<br>Ryan - we could just prohibit it<br>Tim - Agree, but lots of web servers are running under .arpa<br>Ryan - under .arpa, or using an IP address?<br>Tim - could be the IP, but people are getting certificates for the .arpa domain. All that I’ve seen are from Let’s Encrypt so maybe the certs are being automatically created.<br>Ryan - in Caddy V1 (off by default in V2), it automatically tries to get a cert.<br>Corey - a couple of web servers are running at a class B network, meaning someone explicitly created an A record pointing to a web server. This looks intentional. Those certs are coming from a large CDN.<br>Tim - this may break something. Moving to “on deck” and maybe we can make some progress<br>Tim - ‘Defining specific redirect response codes for HTTP’. This has been discussed a fair amount.<br>Ryan - draft language has been circulated. Would like to get this out in the next few weeks.<br>Corey - should there be more discussion of the security properties on a future call?<br>Tim - yes, should be discussed again. Moving to VWG review column.<br>Tim - Moving to the ‘on deck’ column. ’Validation Summit method 8 Ballot’. Thinking we were done with Validation summit methods.<br>Wayne - we removed ‘any other method’ for IP addresses, but haven’t gone back and reviewed the IP validation methods<br>Ryan - there was a question if method 8 was even appropriate. We could propose forbidding it.<br>Tim - ‘Standardize State and Province names’.<br>Tim - ‘Define standard CAA semantics for limiting issuance to DV/OV/EV’. On the back burner now. Move to backlog.<br>Tim - ‘Information reuse’ can stay - just added<br>Tim - Looking at the ‘in-process’ list. Should ‘Create Allow-list of Registration agencies…’ be here? Moved to backlog.<br>Tim - ‘Clarify requirements for the SubjectOU field in BR 7.1.4.2.2’. We need to get back to this. Will put it on the agenda for next time.<br>Tim - move ‘Permit the inclusion of LEIs’ to backlog<br>Tim - ‘Validation Summit method 10 - ALPN’. Wayne was going to work on this<br>Wayne - still planning to move this forward.<br><br><div>## Certificate Profiles</div><div>Tim - We’re out of time. Any quick updates on certificate profiles? No.</div><br><div>## Transitioning from Trello to GitHub</div><div>Tim - on to the topic of moving from Trello to GitHub. Tim created a ‘validation subcommittee’ label in GitHub that can be attached to issues.</div>Wayne - we can create a project and then a board very similar to Trello to organize those issues. We just need someone to do the grunt work of moving them from Trello to GitHub<br>Tim - we can discuss on the next call after everyone has had a chance to consider moving to GitHub projects.</div>