[cabfpub] .onion proposal

[Ryan Sleevi]

On Mon, Dec 1, 2014 at 4:40 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:

> 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
>

Hi Jeremy,

This is a *substantial* improvement, so thanks for taking the time and
gathering feedback on this! I think it's nearly something that we'd be able
to support in principle (and then we can haggle over formatting). I've made
several comments below that I think structurally or materially affect the
proposal, but hopefully aren't too onerous for you.


>
> --------------------------------------
> 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
>

I think this is actually a pretty weak argument. I would instead point to
the fact that powerful web platform features are being restricted to secure
origins, and that onion domains have not been recognized as secure origins
(in part, due to the lack of IANA registration)

That is, asking CAs to change practices because it makes it easier for
servers = not good. Asking CAs to change practices because it helps
browsers improve online security = hopefully good.

(For the CAs not familiar, you can read the non-WG-adopted editor's draft
at https://w3c.github.io/webappsec/specs/powerfulfeatures/ - in particular,
https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-feature-powerful
)


>     - Removing the existing 'Invalid Certificate' warning when accessing a
> .onion URL over https from a standard browser
>

Again, you're underselling the proposal here. Just because a site wants
'pretty' doesn't mean it's a good thing. However, encouraging site
operators NOT to condition users to click through security warnings is a
movement that (hopefully) all CAs and Browsers can fully get behind!


>     - 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.
>

Which document is this an amendment to?
https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf (which your previous
proposal was amending) has SANs at 9.2.1, not 9.2.2

I'm guessing you meant
https://cabforum.org/wp-content/uploads/EV-V1_5_2Libre.pdf (which has SAN
as 9.2.2), and makes far more sense as a document and in the broader scope
of what requirements you're changing.

If so, then I don't think the revocation requirement makes sense to add to
9.2.2, since it's also affecting CNs (9.2.3). It would seem to make more
sense to add the revocation requirement directly to Appendix F, which can
then back-reference 9.2.2 / 9.2.1 in full.

It also seems like 11.7 should be updated to refer to 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.
>

Do you really mean "raw Public Key" or do you instead mean the DER-encoding
of an ASN.1 SubjectPublicKeyInfo?

Note the language from
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21#section-2.4
tries to deal with some of the nuances here. In particular, the SPKI makes
sure that the _algorithm_ is also incorporated into the hash.


> 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.


Isn't this all redundant? That is, if it's an amendment to the EVGs, then
all of this is true already, and the only thing you're changing is the
domain validation portion.

Or did you mean that the only requirements incorporated here are for the
subject fields, and that other requirements (such as 11.13 / 11.11) aren't
required?


> 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.
>

Is there a .well-known URI registered? If not, then just like a new
extension is being defined above (Item 1), then you need to follow the IANA
registration of the .well-known URI (
https://tools.ietf.org/html/rfc5785#section-5.1 ).

Note that this is a good thing no matter what - having the well-known URI
documented is the same value as documentation of email addresses in BR's
11.1.1 p4 .

I'm sure Mark Nottingham would be happy to help with securing a preliminary
registration for a URI, which could then be referenced in this doc, and
this doc would be the specification. Or, if that's totally not workable, he
can tell you that too :)


> 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.
>

Sounds like you need to add two new OIDs to describe the RFC 2986
extensions to appear in the Attributes section of the
CertificationRequestInfo to specify how these random values are
encoded/structured.

I suspect you can just say two OIDs, whose contents are OCTET STRING, as
the nonce/counter-nonce. The distinct OIDs are to avoid any hijinks with
ordering of SETs and substitutes. Anyone requesting a .onion name shouldn't
have (too hard) a time bending certutil or openssl to do this - it really
isn't that hard (heck, Chrome plays with this stuff for unit tests)

Is there a minimum amount of entropy required? If so, seems like it should
be stated.


>
> 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.
>

From: "include a wildcard character in the Subject Alternative Name
Extension and Subject Common Name Field as the leftmost character"

To: "include a wildcard character _as_ the leftmost label of the Subject
Alternative Name Extension and Subject Common Name Field"

Why: Makes it explicit that *abc.hiddenservice.onion is an invalid cert,
but *.hiddenservice.onion is valid. The former is allowed by RFC 2818, but
it's awful and we shouldn't perpetuate it.


>
> 5.      CAs MUST NOT issue a Certificate containing an .onion Domain Name
> with a validity period longer than 15 months.
>

Note: I like this, but any idea what the implications are for Section 11.14
with respect to these certs?


>
>
>
> -----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
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141201/3c251144/attachment-0003.html>