[cabfpub] DV issuance for next-generation onion services

[Seth David Schoen]

Gervase Markham writes:

> I think you make a good case. We would need to specify carefully which
> validation methods make sense but other than that, I agree that the
> cryptographic improvements in NG names make the EV requirement
> superfluous, and that DV should be permitted.

Thanks for the encouragement, Gerv!  The methods that I think are
inapplicable to onion sites are

3.2.2.4.1 Validating the Applicant as a Domain Contact
3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact
3.2.2.4.3 Phone Contact with Domain Contact
3.2.2.4.4 Constructed Email to Domain Contact
3.2.2.4.5 Domain Authorization Document
3.2.2.4.7 DNS Change
3.2.2.4.8 IP Address

This is because onion sites don't use DNS lookups, don't have registrars,
and don't have domain contacts.

That leaves only the three methods based on connecting to the site itself:

3.2.2.4.6 Agreed‐Upon Change to Website
3.2.2.4.9 Test Certificate
3.2.2.4.10 TLS Using a Random Number

It's possible to imagine creating a new validation method based on
properties of the onion site protocol itself (e.g., ability to sign
a challenge with the onion key, or ability to sign a challenge with a
key signed with the onion key).  Right now, my intuition is that this
would add a lot of extra complexity for minimal benefit, so I wouldn't
advocate any onion-specific validation methods.

-- 
Seth Schoen  <schoen at eff.org>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107