<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 1, 2014 at 4:40 PM, Jeremy Rowley <span dir="ltr"><<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>
<br>
Jeremy<br></blockquote><div><br></div><div>Hi Jeremy,</div><div><br></div><div>This is a <b>substantial</b> 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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
--------------------------------------<br>
Proposal<br>
--------------------------------------<br>
<br>
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.<br>
<br>
Applicants want a CA-signed .onion address for several reasons, including:<br>
- Architectural reasons, where the existing web server expects and requires TLS<br></blockquote><div><br></div><div>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)</div><div><br></div><div>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.</div><div><br></div><div>(For the CAs not familiar, you can read the non-WG-adopted editor's draft at <a href="https://w3c.github.io/webappsec/specs/powerfulfeatures/">https://w3c.github.io/webappsec/specs/powerfulfeatures/</a> - in particular, <a href="https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-feature-powerful">https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-feature-powerful</a> )</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- Removing the existing 'Invalid Certificate' warning when accessing a .onion URL over https from a standard browser<br></blockquote><div><br></div><div>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!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- Public attribution of ownership of the .onion address<br>
<br>
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.<br>
<br>
9.2.2. Subject Alternative Name Extension<br>
Certificate field: subjectAltName:dNSName<br>
Required/Optional: Required<br>
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.<br></blockquote><div><br></div><div>Which document is this an amendment to?</div><div><a href="https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf">https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf</a> (which your previous proposal was amending) has SANs at 9.2.1, not 9.2.2<br></div><div><br></div><div>I'm guessing you meant <a href="https://cabforum.org/wp-content/uploads/EV-V1_5_2Libre.pdf">https://cabforum.org/wp-content/uploads/EV-V1_5_2Libre.pdf</a> (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.</div><div><br></div><div>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.</div><div><br></div><div>It also seems like 11.7 should be updated to refer to Appendix F.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Appendix F – Issuance of Certificates for .onion Domain Names<br>
A CA may issue an EV Certificate containing the .onion Domain Name provided that issuance complies with the requirements set forth in this Appendix:<br>
1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31)<br>
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:<br>
cabf-TorServiceDescriptorHash OBJECT IDENTIFIER ::= { 2.23.140.1.31 }<br>
TorServiceDescriptorHash:: = SEQUENCE {<br>
algorithm AlgorithmIdentifier<br>
subjectPublicKeyHash BIT STRING }<br>
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.<br></blockquote><div><br></div><div>Do you really mean "raw Public Key" or do you instead mean the DER-encoding of an ASN.1 SubjectPublicKeyInfo?</div><div><br></div><div>Note the language from <a href="http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21#section-2.4">http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21#section-2.4</a> tries to deal with some of the nuances here. In particular, the SPKI makes sure that the _algorithm_ is also incorporated into the hash.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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. </blockquote><div><br></div><div>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.</div><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> The CA MUST verify the Applicant’s control over the .onion Domain Name using one of the following:<br>
<br>
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.<br></blockquote><div><br></div><div>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 ( <a href="https://tools.ietf.org/html/rfc5785#section-5.1">https://tools.ietf.org/html/rfc5785#section-5.1</a> ).</div><div><br></div><div>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 .</div><div><br></div><div>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 :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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)</div><div><br></div><div>Is there a minimum amount of entropy required? If so, seems like it should be stated.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>From: "include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the leftmost character"<br></div><div><br></div><div>To: "include a wildcard character _as_ the leftmost label of the Subject Alternative Name Extension and Subject Common Name Field"<br></div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
5. CAs MUST NOT issue a Certificate containing an .onion Domain Name with a validity period longer than 15 months.<br></blockquote><div><br></div><div>Note: I like this, but any idea what the implications are for Section 11.14 with respect to these certs?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class="im"><br>
<br>
<br>
-----Original Message-----<br>
From: Gervase Markham [mailto:<a href="mailto:gerv@mozilla.org">gerv@mozilla.org</a>]<br>
</span><span class="im">Sent: Thursday, November 20, 2014 3:15 AM<br>
To: Brian Smith<br>
Cc: Jeremy Rowley; <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>
Subject: Re: [cabfpub] .onion proposal<br>
<br>
</span><div class=""><div class="h5">On 19/11/14 20:22, Brian Smith wrote:<br>
> Also, when you say "it should certainly be allowed," do you mean that<br>
> you verified that browsers do the correct thing with respect to SPDY<br>
> and HTTP/2 connection coalescing when a certificate has both an .onion<br>
> and a non-.onion dNSName subjectAltName? I think TorBrowser probably<br>
> does the right thing, but I could see how it could easily go wrong. It<br>
> seems like unnecessary risk.<br>
<br>
No, you're right, I haven't checked this.<br>
<br>
Gerv<br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
</div></div></blockquote></div><br></div></div>