[cabf_validation] Onion Proposal

[Roland Shoemaker]

Let's Encrypt will endorse this ballot.

Thanks,
Roland

On Thu, Jan 16, 2020 at 9:32 AM Wayne Thayer via Validation <
validation at cabforum.org> wrote:

> 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.
>>>>
>>> _______________________________________________
> 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/20200116/349ffdd1/attachment.html>