[cabf_validation] Onion Proposal

[Wayne Thayer]

The only feedback I've received is to update the redline to be immutable by
referencing commits [1].

Please let me know if you are willing to endorse this ballot. Once I have
two endorsers, I'll begin the discussion period.

Thanks,

Wayne

[1]
https://github.com/cabforum/documents/compare/16a5a9bb78a193266f8d1465de1ee5a1acf5d184..fded04ad7f0390931d38af225bea46a4742fb631

On Thu, Jan 2, 2020 at 11:03 AM Wayne Thayer <wthayer at mozilla.com> wrote:

> Here is a draft ballot for review. I'm still looking for feedback on the
> proposal and two members to endorse.
>
> ==========================
> Ballot SCXX: Version 3 Onion Certificates
>
> Purpose of Ballot:
>
> This ballot will permit CAs to issue DV and OV certificates containing Tor
> onion addresses using the newer version 3 naming format.
>
> In ballot 144, later clarified by ballots 198/201, the Forum created rules
> for issuing EV certificates containing onion addresses. A primary reason
> for requiring EV level validation was that onion addresses were
> cryptographically weak, relying on RSA-1024 and SHA-1. More recently a
> newer "version 3" addressing scheme has removed these weaknesses. For much
> the same reason that EV certificates are not always a viable option for
> website operators (e.g. sites operated by individuals), many onion sites
> would benefit from the availability of DV and OV certificates for version 3
> onion addresses.
>
> The Tor Service Descriptor Hash extension required in the EV Guidelines to
> contain the full hash of the keys related to the .onion address is no
> longer needed as this hash is part of the version 3 address.
>
> Older version 2 onion addresses are still in use, so this ballot does not
> remove the existing EV Guidelines requirements for onion names.
>
> Reference to discussion of EV onion certificates:
> https://cabforum.org/pipermail/public/2014-November/004569.html
>
> Reference to reasons we required EV in the past:
> https://cabforum.org/pipermail/public/2015-November/006213.html
>
> Reference to prior discussion of this topic:
> https://cabforum.org/pipermail/public/2017-November/012451.html
>
>
> The following motion has been proposed by Wayne Thayer of Mozilla and
> endorsed by XXX of YYY and XXX of YYY.
>
>
> -- MOTION BEGINS --
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” as follows, based on Version
> 1.6.7, or based on Version 1.6.7 as modified by ballot SC25:
>
> ADD a paragraph to section 3.2.2.4 of the Baseline Requirements as defined
> in the following redline:
> https://github.com/cabforum/documents/compare/master...wthayer:br-onion
>
> ADD Appendix C to the Baseline Requirements as defined in the following
> redline:
> https://github.com/cabforum/documents/compare/master...wthayer:br-onion
>
>
> This ballot modifies the "Guidelines for the Issuance and Management of
> Extended Validation Certificates" as follows based on version 1.7.1:
>
> MODIFY Appendix F as defined in the following redline:
> https://github.com/cabforum/documents/compare/master...wthayer:br-onion
>
> -- MOTION ENDS --
>
>
> This ballot proposes two Final Maintenance Guidelines.
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
>
> Start Time: TBD UTC
>
> End Time: No earlier than TBD UTC
>
> Vote for approval (7 days)
>
> Start Time: TBD
>
> End Time: TBD
>
> On Mon, Dec 23, 2019 at 3:37 PM Wayne Thayer <wthayer at mozilla.com> wrote:
>
>> Thanks Jacob and Roland. I've attempted to address your comments:
>> https://github.com/wthayer/documents/commit/6e590309cca47737454790f452369769bf7281eb
>>
>> As I believe you are suggesting, I removed the requirement defining how
>> to communicate the nonce only to the Applicant.
>>
>> I also made a few other changes to the draft:
>> * Add random value expiration:
>> https://github.com/cabforum/documents/commit/14235f2e21df5cc75fbd151f91cba277af2df762
>> * Anticipate changes to domain validation method #6:
>> https://github.com/cabforum/documents/commit/4945ebd94fe70e3762600f39746e30d266d15aaf
>>
>> Thanks,
>>
>> Wayne
>>
>> On Thu, Dec 19, 2019 at 2:18 PM Jacob Hoffman-Andrews <
>> jsha at letsencrypt.org> wrote:
>>
>>> Thanks for moving this forward.
>>>
>>> My colleague Roland Shoemaker pointed out that this proposal introduces
>>> the term "Verified Method of Communication," which is only defined in the
>>> EVGLs, not the BRs. There's a similar definition in the BRs:
>>>
>>> Reliable Method of Communication: A method of communication, such as a
>>> postal/courier delivery address, telephone number, or email address, that
>>> was verified using a source other than the Applicant Representative.
>>>
>>> However, this is only used in the context of establishing Subject
>>> Identity Information to be included in the certificate. For certificates
>>> without Subject Identity Information, this is probably not necessary; that
>>> is, proof of control of the private key corresponding to the Onion address
>>> is sufficient on its own, so communication could be established, e.g.
>>> through an API account created by the Applicant Representative.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20200116/d1716bde/attachment.html>