[cabf_validation] Notes of Validation WG Meeting 2017-Nov-16

Rick Andrews Rick_Andrews at symantec.com
Tue Nov 21 13:43:37 MST 2017


I listened to the recordings of the F2F meeting (thanks, Ben). Here's a
rough summary:

 

----- ----- ----- -----

Validation Working Group topics

*	Proposed CAA flags: Validation methods, account identifier,
certificate types, and brands

 

CAA issues from Jeremy's report of Validation Working Group

*	Lack of clarity on how to behave if DNS didn't respond
*	Lack of quality in DNSSEC implementations
*	RFC not mature enough
*	Discussion about split horizon
*	Failures due to CNAME loops
*	Malformed CAA records
*	Lesson: need a more phased approach to rolling it out
*	Need to know what happens with audits

 

Kirk asked about malformed records. Jeremy said some were missing issuer
names

Wayne suggested better tools were needed to create CT records

Kirk asked what was still pending at IETF? Jeremy said there's an errata not
yet approved, and a new RFC

Wayne asked for clarification on what is a DNS failure. Can you just retry
the query on a particular record, or do you have to retry the entire set of
queries up the chain?

Geoff said BRs don't say to fail closed. Peter suggested it should be fail
open if there's no DNSSEC chain, but fail closed if there is a DNSSEC chain

Wayne asked if you had to use DNSSEC to determine that the zone isn't DNSSEC
protected

Geoff thinks no, we're not required to use DNSSEC to determine this

Wayne asked how we provide clear guidance to implementers, because there was
significant disagreement in the room

Gerv proposes we create a list of all pathological edge cases and decide on
the right approach to each, so all CAs can implement it the same way

The group concluded that you don't need to use DNSSEC to prove the
non-existence of a DNSSEC chain; just look for lack of DS records

Should this be discussed further in the VWG, or a new WG?

Jeremy thought it should perhaps move out of VWG; otherwise it might never
get done

Kirk suggested a subcommittee of the VWG; Tim didn't see any advantage of
that, suggested a new WG

Kirk thought that WGs must be created by ballot

In the new governance structure, this would be a new subcommittee under the
Server group

Gerv thought it would be sad if it were too complicated to create a new WG
in the new governance structure

Geoff volunteered to write some language needed to scope the new WG; Tim
suggested some language

We'll also include other CAA topics like different flags for CAA records

Agreement to create the WG by following what the Bylaws dictate

Wayne asked about how DNAMEs should be handled; Tim suggested the WG should
discuss that

There's one errata for CNAMEs and another for DNAMEs; we voted in the CNAME
one but not the DNAME one

A small number of people (not just those trying to QA CAA) use DNAMEs

Tim thinks CABF should vote on the way to interpret DNAMEs; Wayne thought it
was best done by the WG

Tim said that Andrew worked up a test case with DNAME but concluded that it
would be best to do an errata to remove DNAME from RFC 6844

Peter explained that once an RFC is published by IETF, they're immutable.
But sometimes there's interest in updating it; that results in a new RFC
number.

People can file errata, and they're tracked, but they can be accepted or
rejected. Who gets to decide? Peter thinks it's the WG chair or Area
Director

Kirk asked if we should come up with our own corrections to 6844 and file an
errata for it, then modify the BRs to require conformance to that errata

Gerv thought that a WG should be formed to determine what errata might be
proposed

 

----- ----- ----- -----

 

In October, Geoff proposed the formation of a WG, and discussion ensued in
which several people (Jacob Hoffman-Andrews, Ryan) felt that it was better
to participate in the IETF LAMPS WG. The thread died out after a week. On
11/16, Phillip said that the LAMPS group discussed a path forward to work on
CAA in the IETF. Ben suggested that we discuss this at the next CABF
teleconference. I believe we need to decide if we need a CABF WG or just
participate in LAMPS.

 

-Rick

 

Rick Andrews

Senior Technical Director

O 650 527 9506 | M 650 933 3648



 

 

 

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Ben
Wilson via Validation
Sent: Sunday, November 19, 2017 2:32 PM
To: CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: [cabf_validation] Notes of Validation WG Meeting 2017-Nov-16

 

Here are my notes of our call last Thursday for the Validation WG,
11-16-2017.  Feel free to suggest changes.

 

Present:  Tim Hollebeek, Tom Ritter, Frank Corday, Ben Wilson, Bruce Morton,
Rick Andrews, Robin Alden, Rich Smith, Ken Myers, 

 

We reviewed the notes of the Face-to-Face meeting in Taiwan.  We reviewed
backlog ballots.  SRV Names are currently being discussed on the list, and
so that discussion can continue there.  Latin Notary clarification ballot
(Ballot 192) already passed in June, and it is unclear whether this ballot
is the same as that one.  So there is some confusion or miscommunication.
If changes need to be made, then we would need a new ballot.

 

Tim will circulate a ballot in about two weeks that clarifies the Random
Value / Request Token / Nonce issues.  

 

Use of Multiple Methods and/or Cross Methods as part of the same domain
validation was discussed at the face-to-face meeting, but more follow-up on
this topic is needed.  This issue might be cleared up more once the random
value / request token / nonce topic is cleared up.  So we may have to wait
on that effort first.

 

>From the F2F notes - document reuse and scope are still confusing and could
use clarification.

 

The Validation WG could go through the Ballot 190 issues list.  Jeremy has
the most current one and needs to circulate it on the list.

IP address validation could also use some work, clarification, etc.  Jeremy
circulated a proposal on 1 October.  Ben hit re-send and re-circulated it.  

 

CAA was also discussed at the F2F.  RFC 6844 discusses how CAA works, but it
doesn't talk about failure cases (CNAME loops etc.), only when all of the
calls succeed.  The recording of the discussion on CAA from the F2F is
available if anyone wants to listen to it.  Rick will listen to it and
provide some feedback.  We also need to see whether there is still support
for a working group on CAA.  The F2F notes indicate that the Validation WG
would create a normalization document.  The notes also indicate that there
was discussion about modifying CAA to include indicators of brands and
certificate types.  

 

The WG discussed BR Section 7.1.4.3.1.b and the use of vanity CAs - that
this concept is already well developed in current CA practice, but the
baseline requirements need to be more explicit in indicating that this
practice is allowed.

 

Bruce raised an add-on topic for discussion.  He had sent an email
suggesting we delete outdated portions of the Baseline Requirements that
talk about internal names and ICANN's adoption of gTLDs.  There was
consensus in the group on the call that these provisions were outdated and
should be deleted.  It was recommended that Bruce send his email to the
Public list and note that the Validation WG didn't see any reason why this
language couldn't be deleted.

 

Adjourned.

 

Next meeting at same time in 3 weeks on 7 Dec. 2017.  Ben will send out a
meeting invite for WebEx.

 

 

Ben Wilson, JD, CISA, CISSP

DigiCert VP Compliance

+1 801 701 9678

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20171121/3e51ccf6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5529 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20171121/3e51ccf6/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5724 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20171121/3e51ccf6/attachment-0001.p7s>


More information about the Validation mailing list