[cabf_validation] London F2F Validation WG Meeting Notes

[Wayne Thayer]

Here are my notes from the Validation WG F2F Meeting in London on June 5,
2018. I don't believe that working group minutes are officially reviewed
and published, so if you attended and find anything to be inaccurate,
please reply on the list with you corrections.
==============
1. Bruce's validation method - placing email address in DNS txt or CAA
record.
- Tom: Why use email if the person has DNS control?
- Because it allows an email address (or possibly a phone number) to be
persistently delegated in a DNS record and used for validations, similar to
pulling an email from WHOIS (since GDPR is causing WHOIS to go away)
- CAA is the right place for this info. Tim has drafted a spec. Needs to go
through IETF but only needs an expert review, not an RFC
- Next steps: Tim will circulate CAA tag spec (separate document or perhaps
a BR appendix that is later separated) to CAB Forum, then get it adopted
via the CAB Forum or IETF. Then notify IANA. Then need to update BRs to
permit this method.

2. Ballot 225 - Improvements to EV Guidelines Sec. 11.6 – Operational
Existence
- Cecilia described option B which does away with QIIS and adds QTIS for
validating operational existence. It also requires verification of a Demand
Deposit Account.
- Ryan: what are we trying to prove?
- Geoff: operational existence
- Ryan: if we don't trust QIIS here, why do we trust it somewhere else?
- Ben: Originally we presumed that 3 years of legal existence were enough
to confirm operational existence.
- Kirk: perhaps the bank account should have a minimum balance or the tax
return should show that the entity had some revenue.
- Wayne: The problem is that browsers display company name and jurisdiction
(country) in the chrome, but that information is not unique so it opens up
a phishing vector.
- Geoff: there are really 3 issues here. First is name collisions. Second
is operational existence. Third is physical existence - must perform
business activities at a location.
- Tom: is it possible to perform business activities at no location?
- Mike: excluded purposes for EV includes operational existence, but the
secondary purposes include preventing phishing. Geoff clarified that EV
doesn't guarantee this, but that it attempts to prevent it.
- Tim: maybe we should be looking at name collisions rather than
operational existence
- Kirk: getting back to ballot, it removes QIIS from operational existence
checks. Including a waiting period may also be a good idea.
- Ryan: Orgs are created for and and to sold to criminals
- Ryan: We should look at our use of QIIS across the board.
- Jeremy: Operational existence is the only area where QIIS information is
used without being coupled some further validation like a phone call.

BREAK

3. Validation summit review
- Findings doc:
https://docs.google.com/document/d/1aJiOzYVTpoAPVWDucnp20cTO2PR_cRsHncvkhlrcR10/edit#heading=h.rvt81ejrzk00
Method 3 Phone Contact with Domain Contact - we should not allow a phone
validation of 'a.example.com' be used for 'b.example.com'
- It was suggested that a script for the call be provided
Method 2
- Should separate random value from secret value.
- Geoff: might the intention be to allow SOA records? - one of the fields
is the contact email address. Perhaps this solves the GDPR issue? But most
people may not be aware of this or have the SOA email address set
incorrectly.
Method 6 Website change - which things should we focus on?
- Ryan: we should get highly prescriptive on this. Maybe it's an appendix
to the BRs? ACME http-01 method is a good example of a highly specified
approach.
- Tim: this needs a security analysis
- Added ACME http-01 analysis to Trello board
Method 7 DNS challenge
- Tim: in better shape than most
Methods 9 and 10 exist but can't be used by most CAs
- Doug asked if we can replace them with the new ACME tls-alpn method. This
is on the Trello board for review
Method "C" is now Bruce's ballot discussed at the beginning of this meeting

4 Specifying and disclosing validation methods
- For CAA, how should we specify validation methods.
- Tom: human-readable methods would be better
- Sleevi: use IANA to register human-readable names. Or we could create a
table in the BRs.
- In the certificate, OIDs are a good specific approach. For CAA, a more
general restriction may be desirable, such as "any version of any email
method"
- Tim: start with a simple approach that whitelists "version 1" methods for
CAA
- Tom: could a similar approach of documenting the methods used to perform
EV validation be used to address the issue with operational existence
described in ballot 225?
- Ben: we have to be careful about how much detail we're adding to a
certificate. Certificate size is an issue, both for DTLS and TCP congestion
window.
- Tom: need to find a balance or technical solution for browsers that may
want lots of details versus other uses that require minimal cert sizes.
- Tim: perhaps this information should be stored in a separate append-only
metadata log
- Geoff: why put data into logs that browsers have no plan to use?
- Tom: I want to use all the info to make security decisions for users

5. Summary
What are the most important things to move forward with?
- Doug - update methods 6, 9, and 10 and add Bruce's method?
- Specifying domain control methods in CAA and certs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180606/1a9d5e99/attachment.html>