[cabfpub] .onion proposal
Jeremy Rowley
jeremy.rowley at digicert.com
Mon Dec 1 16:40:05 UTC 2014
Thanks for the comments so far. Here's an updated proposal based on some of the recommendations I received. The proposal requires EV, limits the validity period to 15 months, and clarifies how validation of the service occurs. Any additional thoughts? If not, I'll be looking for endorsers.
Jeremy
--------------------------------------
Proposal
--------------------------------------
Several organizations have expressed a desire for an end-entity SSL certificate valid for their .onion Hidden Service address signed by a Certificate Authority (CA) present in browser trust stores.
Applicants want a CA-signed .onion address for several reasons, including:
- Architectural reasons, where the existing web server expects and requires TLS
- Removing the existing 'Invalid Certificate' warning when accessing a .onion URL over https from a standard browser
- Public attribution of ownership of the .onion address
This document is intended to set clear guidelines on how a CA may issue certificates for .onion addresses. This proposal authorizes the issuance of EV TLS certificates only under the stated provisions.
9.2.2. Subject Alternative Name Extension
Certificate field: subjectAltName:dNSName
Required/Optional: Required
Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject’s server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. As of January 1, 2015, each CA MUST revoke all Certificates issued where the Subject Alternative Name extension of Common Name field contain a .onion Domain Name unless the Certificate was issued in compliance with Appendix F.
Appendix F – Issuance of Certificates for .onion Domain Names
A CA may issue an EV Certificate containing the .onion Domain Name provided that issuance complies with the requirements set forth in this Appendix:
1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31)
The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format:
cabf-TorServiceDescriptorHash OBJECT IDENTIFIER ::= { 2.23.140.1.31 }
TorServiceDescriptorHash:: = SEQUENCE {
algorithm AlgorithmIdentifier
subjectPublicKeyHash BIT STRING }
Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the raw Public Key of the .onion service and SubjectPublicKeyHash is the value of the hash output of the raw Public Key.
2. The CA MUST verify the Applicant’s legal existence in accordance Section 11.2, the Applicant’s assumed name (if applicable) in accordance with Section 11.3, the Applicant’s physical existence in accordance with Section 11.4, the Applicant’s method of communication in accordance with Section 11.4, the Applicant’s operational existence in accordance with Section 11.6, the name, title, and authority of the Contract Signer and Certificate Approver in accordance with Section 11.8, the signature on the Subscriber Agreement and EV Certificate Request in accordance with Section 11.9, and approval of the EV Certificate Request in accordance with 11.10. The CA MUST verify the Applicant’s control over the .onion Domain Name using one of the following:
a. The CA MAY verify the Applicant’s control over the .onion service by posting a specific value at a well-known URL under RFC5785.
b. The CA MAY verify the Applicant’s control over the .onion service by signing a Certificate Request using the .onion public key if (i) the signature contains a random value chosen by the CA that prevents a fraudulent applicant from obtaining the signed statement within the signature and (ii) the signature contains a random value chosen by the Applicant that prevents the CA from choosing the entire contents of the signed statement.
4. Each Certificate containing a .onion Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the leftmost character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements.
5. CAs MUST NOT issue a Certificate containing an .onion Domain Name with a validity period longer than 15 months.
-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org]
Sent: Thursday, November 20, 2014 3:15 AM
To: Brian Smith
Cc: Jeremy Rowley; public at cabforum.org
Subject: Re: [cabfpub] .onion proposal
On 19/11/14 20:22, Brian Smith wrote:
> Also, when you say "it should certainly be allowed," do you mean that
> you verified that browsers do the correct thing with respect to SPDY
> and HTTP/2 connection coalescing when a certificate has both an .onion
> and a non-.onion dNSName subjectAltName? I think TorBrowser probably
> does the right thing, but I could see how it could easily go wrong. It
> seems like unnecessary risk.
No, you're right, I haven't checked this.
Gerv
More information about the Public
mailing list