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

[Ryan Sleevi]

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> 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
> https://cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20200320/f8804f13/attachment.html>