[cabf_validation] Minutes of 11 April 2019

Thu Apr 11 22:06:09 MST 2019

I have some concerns about the accuracy of the minutes posted, please 
check in-line.

I must admit that capturing some word-for-word expressions like "they 
can do whatever they want", "CABF can do what it likes" in the minutes, 
leaves me a somewhat negative impression. It changes the process from 
"taking minutes", to "transcribing" what was actually said, which serves 
a different purpose. The purpose of minutes, at least as I understand 
it, is to convey the concepts/argument and a summary of what was 
discussed along with any meaningful results out of these discussions. We 
expect to see some dialogues that provide context, especially when it's 
important to document which member supported which argument. However, 
the minutes should mainly try to capture the concepts/arguments and 
rarely the exact words/expressions used, especially when these 
words/expressions don't add anything meaningful to the concept/argument.

Forgive me for this observation, I know that taking minutes is a very 
hard and time consuming process and we should thank everyone 
volunteering to take minutes, I've been doing it quite a lot recently! I 
am just trying to ensure that the minutes produced by the SCWG and the 
Forum in general, meet the expectations of the readers :-)

Dimitris.

On 11/4/2019 7:15 μ.μ., Robin Alden via Validation wrote:
>
> Present:
> Robin Alden
>
> Tim Hollebeek
>
> Kirk Hall
>
> Dimitris
>
> Enrico
>
> Doug Beattie
>
> Ballot status
>
> SC17 being discussed among endorsers.
>
> SHould be a version out shortly.
>
> Ballot for the phone validation went out this morning from Doug.
>
> Trello board.  Figure out our priorities.
>
> Continuing the validation summit is the direction, but how do we get 
> there.
>
> SC7 passed.
>
> Not making progress on getting the last 3 questions about the HTP 
> validation method figured out.
>
> That's the method 6 ballot.
>
> Doug: Ryan S suggested we write it up and he would comment on that.
>
> Tim H not had time to write it, yet.
>
> 9 - done - removed.
>
> 10 - waiting for the IETF ALPN draft to be issued.
>
> On deck:
>
> Methods 2, 4, 7, 8, 12
>
> Should method 2 be split into multiple methods?
>
> 2 - Email, Fax, SMS, or postal mail to domain contact
>
> 4 - constructed email
>
> 7 - DNS
>
> 8 - IP address.  Less interesting after the 'other method' got cleaned up.
>
> 12 - Godaddy method.
>
> So, 2 and 7 up next
>
> We looked at method 2, and decided it's in fairly good shape. No good 
> security justification for an update, so leave it alone.
>
> Method 7,
>
> there are two allowed values for the DNS label (acme-something and 
> _pki-validation).  Probably not much value in fixing this one thing in 
> isolation.
>
> Dimitris: What are we trying to solve with this underscore?
>
> So IT admins know
>
> including the specific underscore name means that IT/DNS admins have a 
> mechanism for protecting these validation labels while not otherwise 
> restricting the delegation of DNS names if they so wish.
>
> Maybe we leave this alone, too.
>
> For method 8, we had a previous ballot that names ACME methods http-01 
> and alpn-01 referring to a specific RFC draft number, so that sets a 
> precedent to do the same (use a specific draft version number) here too.
>

I have a feeling that the method numbers are a little mixed up. I recall 
discussing this for method 10.

> Method 12, whether we want to enhance it to allow non-affiliate 
> relationships?
>

I believe we agreed that this method is best suited for Registrars (and 
their affiliates) only. It is very hard to set requirements for 
non-affiliate entities to access this information securely.

> Method 4
>
> Is the method good?
>
> Are some of the 5 names better than others?
>
> Some in rfc2142, some not.
>
> Not much harder to protect 5 names than 4.
>
> Some might be slightly better/worse than others, but hard to discriminate.
>
> Knocking one off is not much of a gain.
>
> Not worth addressing.
>
> Quick look at the backlog..
>
> DNSSEC for CAA when the domain name is DNSSEC enabled. (DNSSEC is hard)
>
> CAA Logging requirements. (disappeared)
>
> Definition of applicant in 3.2.2.4 is different to elsewhere.
>
> Is there stuff from http-01 that could be added to the method 6 
> ballot.  Currently allowed to IP address validation.
>

Again, I think this was not for method 6. The http-01 and alpn-01 are 
described as methods 6 and 7 for IP Address validation, and could 
probably be used to replace method 8 for Domain Validation.

> Workaround for DNS fragmentation .  Let's put this one back 'on deck'. 
> Have some of the larger CAs report on whether they are doing it and if 
> it is effective.
>
> (Robin: we are doing it and have had no problems.  Dimitris: We are 
> doing it too.  Easy with open source software.)
>
> AOB?
>
> Kirk: Back to SC17..
>
> Dimitris and I were on an 'open banking Europe' call this morning.
>
> ETSI says CABF can do what it likes on SC17, because we're only going 
> to use another method (...)
>

Just to clarify, this was not an ETSI meeting, so there were no 
statements from ETSI. Kirk mentioned that, at that meeting, it was 
discussed that the banking industry (not ETSI) has already prepared for 
the use of the subject:organizationIdentifier to carry the necessary 
information for PSD2 and does not intend to use an extension proposed in 
ballot SC17, at least at this time.

> It's odd to have to subsections of 9.2 to have two ways of coding the 
> same info, and wonder if it would be smarter to make them 9.2.8a and 
> 9.2.8.b so if one gets removed you don't get a blank in the list.
>
> My bigger concern is.. why are we mixing extensions and subject fields 
> together.  (9.2.2 SANS field is an extension)
>
> 9.2.8 - you can't include anything else in the Subject information.  
> Will be renumbered.  That does not preclude putting in additional 
> subject fields (e.g. LEI number).
>
> Please include that in the next draft.
>
> We have heard that 'CAs can do whatever they want with the subject, as 
> long as the subjectDN is left alone’.
>
I believe Kirk said "We have heard that 'CAs can do whatever they want 
with extensions, as long as the subjectDN is left alone’."

> Would hate to preclude it accidentally.
>
> Tim: I would support that, but I don't think this ballot is the place 
> to address, as it doesn't address that ambiguity.
>
> As for duplicate encoding, I'm not fond of it either, but it does 
> appear to substantially reduce opposition to the ballot.
>

Tim also mentioned the technical benefits from using an extension that 
improves encoding.

> Kirk: What about 9.2.8 and 9.2.9 into the same section?
>
> Tim: Willing to accept organizational changes like that.
>
> Kirk: What does it mean to put an extension in 9.2?
>
> Tim: Before Dimitris pointed out that we already have a precedent for 
> extensions in 9.2, I was thinking of moving it out.
>
> It may nonetheless be clear to move it to the information section of 
> the EVGs.
>
> Dimitris: Yes, and take the SAN extension with it.
>
> Tim: Moving 9.2. means the two related parts are in different parts of 
> the document.
>
> Does that help with 9.2.10?
>
> Kirk: I think it would help, because saying no other info in the 
> SubjectDN can be had except for (this section).
>
> so maybe we do tighten up 9.2.8.
>
> Tim: Worried other people have other interpretations of 9.2.8 that 
> could cause this to drag.
>
> Kirk: except where specified by this section 9.2.x, subject extensions 
> are unregulated.
>
> Tim: Happy to fly that and see if it gets shot down.
>
> It's a wonderful thing that we're working with the EU and getting 
> close to having a workable solution.
>
> Kirk: EU banking authority and Open banking Europe - some of these 
> have some inherent confusion, but we'll do what we can.
>
> Tim: We should fix the guidelines so that we are ready for when they 
> have it fully sorted out.
>

I am skeptical about this statement by Tim, and wish we had a recording 
of the meeting to confirm. I recall hearing/saying that although they 
are trying to centralize the registries, the authorization information 
to be included in the orgID field is already publicly available in local 
National Registries. They are trying to coordinate all these National 
Authorities to sync this information with a central registry operated by 
the European Banking Authority (EBA).

> Dimitris: This has benefits beyond just Europe, after (at?) the next 
> F2F we’re going to have a guest speaker talking about LEIs from 
> GLEIF.  Hope to open the road for LEIs in EV certificates.
>
"At the next F2F".

I also mentioned that this ballot is designed to support the extension 
of Registration Schemes to allow for other schemes like LEI.

> Tim: If someone could write up a summary of the current state of the 
> different registries, that would be helpful.
>
> Dimitris: That doesn't exist yet. You can point to the regulatory 
> docs.  I'm trying to untangle it all for my team.  We know which 
> countries have good info and which don't.  Leave it for another month 
> to coordinate with the national banks.  As soon as we have good 
> concrete examples of where to get the info and how to validate it, I 
> could write something up.
>
Dimitris: That doesn't exist yet, at least in the form we expect. We 
could point to the regulatory docs.  I'm trying to untangle it all for 
my team.  We know which countries have good info in the central 
registries and which don't. Leave it for another month for EBA to 
coordinate with the national banking authorities.  As soon as we have 
good concrete examples of where to get the info and how to validate it, 
I could write something up.

> Kirk: Let's see that we say it's OK to include a LEI in a cert, 
> RFC5280 says the subject as to be unique, should we consider how we 
> encode an LEI as an extension?
>

"Kirk: Let's say that it is OK to include a LEI in a cert. Could we use 
multiple instances of the OrgID attribute in the subject of the 
certificate? Is there a requirement that prevents us from using multiple 
OrgID attributes to include LEI and other allowed identifiers? Is it 
necessary to encode this additional identifier (e.g. LEI) in an extension"

> Tim: From a political point of view, meh, but the technical objections 
> to the ETSI TS way is valid.  Creating a new extension means you can 
> have multiple identifiers without risking clashes or challenges on 
> duplications.
>
> Have a section in EVGLs for standardized certificate extensions.
>
> Make sure the validation rules are clear for the green-listed extensions.
>
> Regards
> Robin Alden
>
> Sectigo Limited
>
> *From:*Validation <validation-bounces at cabforum.org> *On Behalf Of *Tim 
> Hollebeek via Validation
> *Sent:* 11 April 2019 14:11
> *To:* CA/Browser Forum Validation WG List <validation at cabforum.org>
> *Subject:* [cabf_validation] Agenda
>
>  1. Assign note taker
>  2. Review trello board / ballot status
>  3. Prioritize work to be done before June meeting
>
>
> _______________________________________________
> 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/20190412/50f01dc7/attachment-0001.html>