[cabfpub] Ballot 144 - Validation rules for .onion names
Moudrick M. Dadashov
md at ssc.lt
Tue Feb 17 13:20:22 UTC 2015
SSC votes: "Yes".
Thanks,
M.D
On 2/17/2015 3:08 PM, haavardm at work wrote:
> Opera votes YES
>
>
> On Tue, Feb 10, 2015 at 7:38 PM, Jeremy Rowley
> <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com>> wrote:
>
> *Here’s the ballot with the two typos fixed:*
>
> Applicants want a CA-signed .onion address for several reasons,
> including:
>
> - 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.
>
> - 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.
>
> - 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.
>
> The following motion has been proposed by Jeremy Rowley of
> DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of
> GoDaddy.
>
> ---------------------
>
> Motion Starts
>
> ---------------------
>
> 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as
> follows:
>
> 9.2.1 Subject Alternative Name Extension
>
> Certificate Field: extensions:subjectAltName
>
> Required/Optional: Required
>
> Contents: This extension MUST contain at least one entry. Each
> entry MUST be either a dNSName containing the Fully-Qualified
> Domain Name or an iPAddress containing the IP address of a server.
> The CA MUST confirm that the Applicant controls the
> Fully-Qualified Domain Name or IP address or has been granted the
> right to use it by the Domain Name Registrant or IP address
> assignee, as appropriate.
>
> Wildcard FQDNs are permitted. As of the Effective Date of these
> Requirements, prior to the issuance of a Certificate with a
> subjectAlternativeName extension or Subject commonName field
> containing a Reserved IP Address or Internal Name, the CA SHALL
> notify the Applicant that the use of such Certificates has been
> deprecated by the CA / Browser Forum and that the practice will be
> eliminated by October 2016. Also as of the Effective Date, the CA
> SHALL NOT issue a certificate with an Expiry Date later than 1
> November 2015 with a subjectAlternativeName extension or Subject
> commonName field containing a Reserved IP Address or Internal
> Name. Effective 1 October 2016, CAs SHALL revoke all unexpired
> Certificates whose subjectAlternativeName extension or Subject
> commonName field contains a Reserved IP Address or Internal Name.
> _Effective May 1, 2015, each CA SHALL revoke all unexpired
> Certificates with an Internal Name using onion as the right-most
> label in an entry in the subjectAltName Extension or commonName
> field unless such Certificate was issued in accordance with
> Appendix F of the EV Guidelines._
>
> 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the
> Issuance and Management of Extended Validation Certificates v1.5.2
> as follows:
>
> 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_.
>
> 11.7 Verification of Applicant’s Domain Name
>
> 11.7.1. Verification Requirements
>
> (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._
>
> (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.
>
> 3) Add a new Appendix F to the Guidelines for the Issuance and
> Management of Extended Validation Certificates v1.5.2:
>
> Appendix F – Issuance of Certificates for .onion Domain Names
>
> A CA may issue an EV Certificate with .onion in the right-most
> label of the 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-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 }
>
> TorServiceDescriptorSyntax ::=
>
> SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash
>
> TorServiceDescriptorHash:: = SEQUENCE {
>
> onionURI UTF8String
>
> algorithm AlgorithmIdentifier
>
> subjectPublicKeyHash BIT STRING }
>
> 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.
>
> 2. 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 having the Applicant provide a Certificate Request
> signed using the .onion public key if the Attributes section of
> the certificationRequestInfo contains:
>
> (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
>
> (ii) An applicantSigningNonce attribute that 1) contains a single
> value with at least 64-bits of entropy and 2) is generated by the
> Applicant.
>
> The signing nonce attributes have the following format:
>
> caSigningNonce ATTRIBUTE ::= {
>
> WITH SYNTAX OCTET STRING
>
> EQUALITY MATCHING RULE octetStringMatch
>
> SINGLE VALUE TRUE
>
> ID { cabf-caSigningNonce }
>
> }
>
> cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 }
>
> applicantSigningNonce ATTRIBUTE ::= {
>
> WITH SYNTAX OCTET STRING
>
> EQUALITY MATCHING RULE octetStringMatch
>
> SINGLE VALUE TRUE
>
> ID { cabf-applicantSigningNonce }
>
> }
>
> cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 }
>
> 4. Each Certificate that includes a Domain Name where .onion is in
> the right-most label of the 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 left-most 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 that includes a Domain Name
> where .onion is in the right-most label of the 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.
>
> 6. On or before May 1, 2015, each CA MUST revoke all Certificates
> issued with the Subject Alternative Name extension or Common Name
> field that includes a Domain Name where .onion is in the
> right-most label of the Domain Name unless the Certificate was
> issued in compliance with this Appendix F.
>
> ----
>
> Motion Ends
>
> -----
>
> The review period for this ballot shall commence at 2200 UTC on
> Thursday, 4 February 2015, and will close at 2200 UTC on Thursday,
> 11 February 2015. Unless the motion is withdrawn during the review
> period, the voting period will start immediately thereafter and
> will close at 2200 UTC on Monday, 18 February 2015. Votes must be
> cast by posting an on-list reply to this thread.
>
> A vote in favor of the motion must indicate a clear 'yes' in the
> response. A vote against must indicate a clear 'no' in the
> response. A vote to abstain must indicate a clear 'abstain' in the
> response. Unclear responses will not be counted. The latest vote
> received from any representative of a voting member before the
> close of the voting period will be counted. Voting members are
> listed here: https://cabforum.org/members/
>
> In order for the motion to be adopted, two thirds or more of the
> votes cast by members in the CA category and greater than 50% of
> the votes cast by members in the browser category must be in
> favor. Quorum is currently nine (9) members– at least nine members
> must participate in the ballot, either by voting in favor, voting
> against, or abstaining.
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
>
>
>
>
> _______________________________________________
> 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/20150217/9f6d3874/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3653 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150217/9f6d3874/attachment-0001.p7s>
More information about the Public
mailing list