[Servercert-wg] Ballot SC27: Version 3 Onion Certificates

[Wayne Thayer]

This is version 3 of ballot SC27: Version 3 Onion Certificates. I received
some feedback that the clarifications to section 3.2.2.4 that were made in
version 2 of the ballot could be misinterpreted. To make it more
understandable without changing the meaning, I converted that paragraph to
bullets, and I have again reset the discussion period to 7 days.

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 Roland Shoemaker of Let's Encrypt and Dimitris Zacharopoulos of
HARICA.


-- 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/16a5a9bb78a193266f8d1465de1ee5a1acf5d184..f7a2dba4a2dd6b7209c71c862ad68dca960b6de9

ADD Appendix C to the Baseline Requirements as defined in the following
redline:
https://github.com/cabforum/documents/compare/16a5a9bb78a193266f8d1465de1ee5a1acf5d184..f7a2dba4a2dd6b7209c71c862ad68dca960b6de9


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/16a5a9bb78a193266f8d1465de1ee5a1acf5d184..f7a2dba4a2dd6b7209c71c862ad68dca960b6de9

-- MOTION ENDS --


This ballot proposes two Final Maintenance Guidelines.

The procedure for approval of this ballot is as follows:

Discussion (7+ days)

Start Time: 25-January 2020 00:00 UTC

End Time: No earlier than 12-February 2020 18:00 UTC

Vote for approval (7 days)

Start Time: TBD

End Time: TBD

On Tue, Jan 28, 2020 at 8:15 AM Wayne Thayer <wthayer at gmail.com> wrote:

> This is version 2 of ballot SC27: Version 3 Onion Certificates. I have
> made the clarifications to section 3.2.2.4 discussed in this thread,
> updated the URL in Appendix C to the canonical link to the Tor spec, and
> reset the discussion period to 7 days.
>
> 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 Roland Shoemaker of Let's Encrypt and Dimitris Zacharopoulos of
> HARICA.
>
>
> -- 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/16a5a9bb78a193266f8d1465de1ee5a1acf5d184..aca8f0cd7896e3941e4a29e5f6957a3496fe5b5c
>
> ADD Appendix C to the Baseline Requirements as defined in the following
> redline:
> https://github.com/cabforum/documents/compare/16a5a9bb78a193266f8d1465de1ee5a1acf5d184..aca8f0cd7896e3941e4a29e5f6957a3496fe5b5c
>
>
> 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/16a5a9bb78a193266f8d1465de1ee5a1acf5d184..aca8f0cd7896e3941e4a29e5f6957a3496fe5b5c
>
> -- MOTION ENDS --
>
>
> This ballot proposes two Final Maintenance Guidelines.
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
>
> Start Time: 25-January 2020 00:00 UTC
>
> End Time: No earlier than 04-February 2020 16:00 UTC
>
> Vote for approval (7 days)
>
> Start Time: TBD
>
> End Time: TBD
>
> On Tue, Jan 28, 2020 at 12:27 AM Tobias S. Josefowitz <tobij at opera.com>
> wrote:
>
>> On Mon, 27 Jan 2020, Wayne Thayer wrote:
>>
>> > Thank you Tobias, that is a great point. My intent was not to require a
>> > cert containing an onion name to contain only onion names. Does the
>> > following change (in all caps) to section 3.2.2.4 fix that?
>> >
>> > The CA SHALL confirm that prior to issuance, the CA has validated each
>> > Fully-Qualified Domain Name (FQDN), other than a Domain Name with
>> .onion in
>> > the right-most label of the Domain Name, listed in the Certificate
>> using at
>> > least one of the methods listed below. In addition, when issuing a
>> > Certificate that includes an FQDN with "onion" as the rightmost label,
>> the
>> > CA SHALL confirm that prior to issuance, the CA has validated each FQDN
>> > listed in the Certificate with "onion" as the rightmost label in
>> accordance
>> > with Appendix C.
>>
>> I think that works, however
>>
>> s/\.onion/"onion"/ for consistency.
>>
>> Tobi
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200205/e4c9fd75/attachment.html>