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

[Dean Coclin]

Revised to reflect clarification:

 

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-certificat
es-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 RA audits, what
roles do these lawyer opinion letters play in the CA/RA ecosystem (as
functioning as RAs) and what level of protection do they need to have?  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. For example, 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 would require going
through, similar to domain validation, to make sure all 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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20200323/1c4862f6/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/20200323/1c4862f6/attachment-0001.p7s>