[cabf_validation] London F2F Validation WG Meeting Notes

[Wayne Thayer]

Perhaps Robin or Ben could tell us if a recording is available?

On Mon, Jun 11, 2018 at 8:21 AM Ryan Sleevi <sleevi at google.com> wrote:

>
>
> 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/20180614/723f6810/attachment.html>