[cabf_validation] Minutes of 11 April 2019

Fri Apr 12 01:22:44 MST 2019

Dimitris,

                Thanks for the corrections and clarifications.

I shall be more succinct in future.

Regards
Robin Alden

Sectigo Limited

From: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr> 
Sent: 12 April 2019 06:06
To: Robin Alden <robin.alden at sectigo.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Minutes of 11 April 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  <mailto:validation-bounces at cabforum.org> <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  <mailto:validation at cabforum.org> <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 <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/20190412/535352cc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5711 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190412/535352cc/attachment-0001.p7s>