[cabf_validation] Minutes of 11 April 2019

[Robin Alden]

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.

 

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

 

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.

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 (...)

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'.

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.

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.

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.

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.

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?

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

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