[cabf_validation] Onion Proposal

Thu Jan 2 12:03:54 MST 2020

Just a side note, Wayne if you introduce a ballot for an official review period, please make sure you replace the redline links with actual commit marks so they are immutable to changes.

Thanks,

Dimitris. 

-----Original Message-----
From: Wayne Thayer via Validation <validation at cabforum.org>
To: CA/Browser Forum Validation SC List <validation at cabforum.org>
Sent: Thu, 02 Jan 2020 20:04
Subject: Re: [cabf_validation] Onion Proposal

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/20200102/8651bac1/attachment.html>