[cabf_validation] London F2F Validation WG Meeting Notes

[Ryan Sleevi]

On Wed, Jun 6, 2018 at 6:43 AM, Wayne Thayer via Validation <
validation at cabforum.org> wrote:

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

Thanks for taking these, Wayne. I know in the spirited discussions, it can
be hard to take notes, participate, and to distill into the actionable bits.

It looks like a decent amount of discussion about the nuance between legal
existence and operational existence may not have been captured. That seemed
to be an existential question related to the nature of this ballot, given
that the definition of operational existence posed was, in effect,
"actively engaged in doing business;", which is enumerated as an excluded
purpose in the EVGs (in Section 2.1.3). Do recordings exist, perhaps from
the dial-in number, that could allow reviewing some of this?


>
> 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
>
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180611/c12e3dea/attachment.html>