[cabf_validation] Minutes from the meeting of 2 August 2018

[Wayne Thayer]

Minutes from the Validation Subcommittee meeting of 2 August 2018

 Attendees: Tim Hollebeek, Ben Wilson, Shelley Brewer, Bruce Morton, Corey
Bonnell, Doug Beattie, Frank Corday, Joanna Fox, Rich Smith, Robin Alden,
Li-Chun Chen, Frank Corday

1. Continue re-direct discussion
Wayne listed types of redirects in the Validation Summit Findings document
[1] under method 6
Tim: do we have a general idea of what the policy should be?
Ben: No, we need to determine what the concerns are.
Tim: the last two on the list (meta-refresh tag and JavaScript) are bad
ideas because they require CAs to run a sophisticated HTML parser that adds
complexity and risk. I don’t think CAs intentionally support these, but
their code may incidentally support it. Is anyone against banning these two?
Bruce: I can’t comment now
Tim: Are people familiar enough with 300s to discuss?
Doug: I can’t think of a good reason why we should allow any of these
Tim: I’m particularly disturbed when a redirect points back to a site run
by the CA. Pointing to another subdomain of the same domain seems
reasonable. But I could also argue that it should be a new validation
method.
Tim: Does everyone need to give this more thought?
Wayne: We should propose banning redirects and see who complains
Tim: Clients like Curl automatically follow redirects, so people may not
recognize the impact.
Corey: Redirects from the base domain to the www subdomain are common.
Banning this will cause some pain to Subscribers.
Tim: Can everyone do some homework to determine what their CA’s current
redirect behavior is?
Wayne: In most cases CAs could check both the www and base name, but that
won’t work if validating the subdomain and validation code is on the base
domain.
Tim: Redirecting to another subdomain of the same domain name might be okay
- both are controlled by the same entity.
Tim: the basic security property of this method is the ability to control
the content of the website, so if www is the same site as the base domain
then that should be okay.

2. Discuss Ballot SC2
Tim: Mainly failed due to it being Summertime and lack of time to review.
Also some discussion about the phone number validation method colliding
with Doug’s method 3 ballot. Decided to split out the phone number portions
to a separate ballot.
Bruce: Updated the text to use ADN per comment from Wayne
Corey: what about splitting out text record to a separate ballot?
Tim: most DNS tools don’t support new CAA tags, so the TXT record is
essential and it’s a widely accepted approach in the IETF because it works.
Wayne: is the use of a specific subdomain a change?
Tim: no, that’s how it was spec’d in ballot SC2. I realize TXT support is
controversial, but most DNS providers don’t support new CAA tags.

3. Validation Summit Method 3 Ballot
Doug: Changed references to domain contact’s phone number rather than WHOIS
registrant. Added info on voicemail handling. Added validation of an ADN.
CA can request to be transferred to the domain contact. Plan is a ballot to
update method 3 with these clarifications, effective immediately. Also add
method 15 for domain contact phone number in CAA and method 16 for domain
contact phone number in DNS TXT record. There will only be a phone number
and no name in these records because they are there specifically for the
purpose of domain validation rather than a more general WHOIS contact phone
number. Doug will send out an updated pre-ballot in the next few days.
Tim: the question of whether you have to ask for someone specific when
making the call is an interesting one. Have to think about that.

4. Validation Methods in CAA, ACME, and IETF
Tim: A lot going on here. There is an ACME draft for specifying validation
methods in CAA. We discussed in London the use of friendly names rather
than OIDs for CAA records. Wayne, the ‘validation method in certificate”
ballot uses OIDs, correct?
Wayne: Correct. Concatenate the validation method number with the OID arc.
Wayne: There should be a mapping between OIDs and names
Tim: I prefer to run this through IETF
Ben:  We would be dependent on IETF for adding validation methods
Tim: It would be an IANA registry so would be relatively easy to update
Tim: Also going to send CAA contact tags through IETF but shouldn’t hold up
introduction of new methods

5. Validation Methods in Certificates
Wayne: my mental model is that certificates are issued as soon as each SAN
passes one method of domain validation, but Doug pointed out on the list
that some CAs might validate with multiple methods. The CA can just choose
which method to indicate in the certificate, or can indicate multiple
methods. The concern is if one method is found to be insecure, then that
doesn’t necessarily mean that the cert needs to be replaced. In fact, CAs
often revalidate rather than reissuing certs when a validation
vulnerability is found. This leads to the conclusion that the validation
method information in a certificate can’t be used to determine that the
certificate needs to be revoked.
Tim: I agree. The BRs state that the CA must validate using “at least one
of the methods below”.
Doug: I also agree, but we don’t know what browsers will do with this
information, so we have to assume that browsers will use it to make trust
decisions.
Wayne: I view this as information, not a way to enforce policies, and this
discussion makes the case for that.
Doug: Can the intent be part of the ballot?
Wayne: Requirements can’t really describe intent, but I’d be happy to add
that to the introductory language of the ballot.
Tim: Another question is the ability to describe which sub-methods were used
Wayne: the ballot expresses the current scheme of describing methods, so
that scheme would need to change first. In the current scheme, we should
break a method with N sub methods into N new methods.
Tim: I agree. Another concern is with CAA, where constantly changing method
numbers could cause problems when certificates are renewed
Bruce: I don’t see method numbers constantly changing once we get through
our review of all the methods. Agree that method 2 should be 3 methods.
Doug: Method 2 could really be 9 methods. Or we could have one method for
all flavors of phone validation, for instance. We need to decide if we want
to make methods more granular. Not convinced it’s worth turning one method
into 9.
Corey: If we don’t make things more granular, there isn’t enough value in
encoding the method into the cert. The OID for the old and new method 10
would be the same.
Tim: Method 10 is a problem child. It needs to be fixed.

[1]
https://docs.google.com/document/d/1aJiOzYVTpoAPVWDucnp20cTO2PR_cRsHncvkhlrcR10/edit#heading=h.29h2q2aeb3nh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180802/0647661b/attachment.html>