<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoPlainText">Now that it’s a new year, I thought we should revive the onion discussion. Here’s the latest proposal. The changes from the last version include use of ASN.1 notation to describe the extensions and a clarification that the certs must
still expire by the current CAB Forum deadline until the onion name is officially reserved by IESG. Any additional commnets?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Applicants want a CA-signed .onion address for several reasons, including:<o:p></o:p></p>
<p class="MsoPlainText">- Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide
a secure origin for the service, moving onion towards use of powerful web platform features.<o:p></o:p></p>
<p class="MsoPlainText">- Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings
and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks.<o:p></o:p></p>
<p class="MsoPlainText">- The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with
additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">This proposal amends the EV Guidelines to provide clear guidelines on how a CA may issue certificates for .onion addresses.
<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">---------------------<o:p></o:p></p>
<p class="MsoPlainText">Proposal<o:p></o:p></p>
<p class="MsoPlainText">---------------------<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Amend the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows:<o:p></o:p></p>
<p class="MsoPlainText">Amend Section 9.2.2 and 11.7.1 as follows:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName<o:p></o:p></p>
<p class="MsoPlainText">Required/Optional: Required<o:p></o:p></p>
<p class="MsoPlainText">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.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">11.7 Verification of Applicant’s Domain Name<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">11.7.1. Verification Requirements<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">(1) For each Fully-Qualified Domain Name listed in a Certificate other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or
the Applicant’s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as “Applicant” for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the
Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate
was issued, the Applicant’s control over the .onion Domain Name in accordance with Appendix F.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">(2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed
character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt
that the Applicant and the target in question are the same organization.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Add a new Appendix F:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">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:<o:p></o:p></p>
<p class="MsoPlainText">1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31)<o:p></o:p></p>
<p class="MsoPlainText">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:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">cabf-TorServiceDescriptorHash OBJECT IDENTIFIER ::= { 2.23.140.1.31 }<o:p></o:p></p>
<p class="MsoPlainText">TorServiceDescriptorHash:: = SEQUENCE {<o:p></o:p></p>
<p class="MsoPlainText"> algorithm AlgorithmIdentifier<o:p></o:p></p>
<p class="MsoPlainText"> subjectPublicKeyHash BIT STRING }<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">2. The CA MUST verify the Applicant’s control over the .onion Domain Name using one of the following:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">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. [NOTE: This is subject to change depending on whether we can register a well-known URL for onion]<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">b. The CA MAY verify the Applicant’s control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains:
<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">(i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and<o:p></o:p></p>
<p class="MsoPlainText">(ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">The signing nonce attributes have the following format:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">caSigningNonce ATTRIBUTE ::= { <o:p></o:p></p>
<p class="MsoPlainText">WITH SYNTAX OCTET STRING<o:p></o:p></p>
<p class="MsoPlainText">EQUALITY MATCHING RULE octetStringMatch<o:p></o:p></p>
<p class="MsoPlainText">SINGLE VALUE TRUE<o:p></o:p></p>
<p class="MsoPlainText">ID { cabf-caSigningNonce }<o:p></o:p></p>
<p class="MsoPlainText"> }<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } <o:p>
</o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">applicantSigningNonce ATTRIBUTE ::= { <o:p></o:p></p>
<p class="MsoPlainText">WITH SYNTAX OCTET STRING<o:p></o:p></p>
<p class="MsoPlainText">EQUALITY MATCHING RULE octetStringMatch<o:p></o:p></p>
<p class="MsoPlainText">SINGLE VALUE TRUE<o:p></o:p></p>
<p class="MsoPlainText">ID { cabf-applicantSigningNonce }<o:p></o:p></p>
<p class="MsoPlainText"> }<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 }<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">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.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">5. CAs MUST NOT issue a Certificate containing an .onion Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate
containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD.
<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">6. On or before January 15, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field containing a .onion Domain Name unless the Certificate was issued in compliance with this
Appendix F.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>