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

Fri Mar 20 14:21:34 MST 2020

Thanks, let me try to re-phrase those areas and send out again.
Dean

From: Ryan Sleevi <sleevi at google.com> 
Sent: Friday, March 20, 2020 3:43 PM
To: Dean Coclin <dean.coclin at digicert.com>; CABforum3 <validation at cabforum.org>
Subject: Re: [cabf_validation] Draft minutes of Validation call March 12, 2020

Thanks for taking these! Wanting to be faithful to the recording and the discussion, I haven't made clear cut suggested wording changes, but have tried to clarify a few points to see if it makes it clearer for summarizing. I'm also happy to go over the recording and make precise suggestions, since I realize you've already put a fair bit of work in here.

On Fri, Mar 13, 2020 at 7:48 PM Dean Coclin via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

I used the recording to make this as detailed as I could but please check for accuracy as there were times where the meaning wasn’t clear.

Attendees: Tim Hollebeek, Dean Coclin, Wayne Thayer, Corey Bonnell, Andrea Holland, Janet Hines, Daniela Hood, Bruce Morton, Robin Alden, Clint Wilson, Joanna Fox, Mike Reilly, Niko Carpenter, Shelley Brewer, Wendy Brown, Li Chun Chen, Ryan Sleevi, Aneta Wojtczak-Iwanicka

Antitrust Statement was read by Tim H.

Agenda: Improving EV validation, Reviewing BR section 7.1 for default/deny issues

Improving EV validation: Dean mentioned the RSA presentation made by a researcher on how cybercriminals were able to obtain EV certs on the Dark Web (see: https://www.rsaconference.com/usa/agenda/the-modus-operandi-of-ev-certificates-fraudsters-findings-from-the-field). The fraudsters registered companies and then used those registrations to obtain lawyer opinion letters and D&B numbers which enabled them to obtain EV certs. They then created websites using those certs which represented a bank and a merchant. This was done as part of a “crime as a service” operation, which the researcher stated, is available on the Dark Web. Dean suggested perhaps as a countermeasure that legal opinion letters be done face to face as one idea. Another idea is to use some sort of mapping program or “street view” to verify that the business is indeed a bank and not a restaurant, for example. Ryan and Tim said that it doesn’t sound like this information is anything new and represents things that have been discussed before. For example, we discussed the need to have a common set of agencies of incorporation (a draft ballot which Ryan recently circulated) since different countries have different qualities of QIIS. Ryan suggested we should figure out the priorities to give us the most value for our efforts. Also in terms of CA’s RA audits, what roles do these lawyer opinion letters play in that?  

Happy to go back to the recording, but the point was not about the "CA's RA audits", but asking to what extent these legal opinion letters were functioning as RAs, and whether or not they should be considered in scope of the CA's audits.

Ryan suggested we take a systemic look at this before rushing to a solution. Tim posed the question, “What is a legitimate company?”. A company that is registered is a “legitimate” company in the jurisdiction it is organized. If the certificate verifies this, is it supposed to go beyond that? Ryan stated verifying legitimacy is more complex. We need to look at “levels of assurance”, analogous to what we did for domain validation, as a way to improve EV validation. 

Er, that reads a bit more supportive of the VWG taking this on than the concern I was trying to raise. I was highlighting we have multiple methods of validating the legitimacy of a company, and they provide different assurance levels. If we want there to be a minimum assurance level, it'd require going through, similar to domain validation, to make sure all the methods achieve that.

Dean said he had discussed requiring companies to be registered for a certain period of time (i.e. 6 months, 9 months, etc) before issuing an EV cert but decided that approach would only cause cybercriminals to “stockpile” registrations until needed. Ryan said that’s exactly what is happening with code signing but said there is value in looking at solutions and suggested a holistic approach is preferred, given other validation priorities to fix.  Tim said this was a good discussion but we should move on to the next topic.

Section 7.1, default deny discussions

Doug had started a document on this topic which Ryan has added to. Ryan suggested the best way to make progress is to have CAs review the list and flag things they disagree with. He also mentioned the draft browser alignment ballot which he has posted, as something CAs should look at. Wayne suggested we look at the section of the BRs on the call (with default/deny in mind) and look at it in real time. 

Ryan said he was keen to explore an approach whereby constructing a cert profile that represents certificates like they really are. The way section 7.1 is constructed creates challenges as it alternates talking about subscriber certs, leaf certs, root certs in different sections and is not aligned with the actual structure of a certificate. A good example is looking at sections 7.1.4.2.1 and 7.1.4.2.2 (subj alt name and subj distinguished name). Most folks thing of subj alt name as later in the cert. He has filed a couple of changes in github where subj alt name talks about reserved IPs or internal names  but that restriction doesn’t actually get propagated to name constraints, hence it’s ambiguous whether you can include that. This might be useful for some of the confusion around what a cross cert is, as an example. This is a much more involved and radical approach. But it would lead us to a common understanding of what’s allowed and what’s not allowed. 

Tim said he is cautiously optimistic about this approach. He believes the document causes confusion as written and that the suggested approach might be more useful. Ryan said this structure seems to be more common for the European colleagues as they are used to this structure. He continued, stating we should look at some high level proposals before continuing as well as looking at some of the CA’s CP/CPS’. Tim suggested we get input from other CAs and participants.  Aneta (Microsoft) said this was a good idea and agreed with the overall approach.  

Ryan asked if we should look at what types of certificates CAs are issuing and what sort of profiles were used, as a starting point (based on incidents he’s seen). Aneta thought this was a fair assumption but asked what Ryan is expecting. Ryan stated we don’t necessarily need a “table” but rather to find out if CAs are doing their systems like this, it can be used as a starting point. Tim said it could be challenging to get this info from CAs and hence it may not be a useful way to obtain it. Ryan agreed but said it could be a way to start discussions. Aneta asked for clarification, if Ryan meant that we should come up with profiles and then ask CAs for their adherence/understanding. Ryan said yes, so that CAs can compare to what they are doing, but wanted to know if this would be useful. Aneta said this would be very useful. Tim characterized this task as “hard” but “important”. Ryan agreed to look up some CP/CPS that he has previously reviewed as examples to frame the issue. This will help with the default/deny implications. Robin implied that there are some examples or ellipsis in their CPS and asked if Ryan was looking to tighten these up. Using extensions as an example, Ryan stated yes and they expect certain validation practices to be used as well as consistency. An example is the subject distinguished name, where they expect more structure. We’ve seen this in the EV discussion, the subordinate CA discussion and the OU discussion, hence providing additional structure and guidance would be beneficial. Aneta asked for clarification on the OU discussion. Ryan summarized that this was discussed at the F2F and revolves around whether OU was permitted in DV certs as the way it’s currently worded, can result in multiple interpretations. 

Tim summarized that we should give Wayne’s idea a try on the next call and see if folks thought that was a useful approach. Corey agreed as long as the section was known ahead of time. Tim said section 7.1. 

Dean Coclin

Minute taker

_______________________________________________
Validation mailing list
Validation at cabforum.org <mailto:Validation at cabforum.org> 
https://cabforum.org/mailman/listinfo/validation

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