[cabfpub] Ballot 169 - Revised Validation Requirements

Fri Aug 5 04:50:16 UTC 2016

SSC votes: "Yes".

Thanks,

M.D.


On 7/28/2016 9:09 PM, Ben Wilson wrote:
>
> Here is the revised Ballot 169
>
> *Ballot 169 - Revised Validation Requirements*
>
> The following motion has been proposed by Jeremy Rowley of DigiCert 
> and endorsed by Tim Hollebeek of Trustwave and Doug Beattie of 
> GlobalSign:
>
> *Background:*  The primary purpose of this change is to replace Domain 
> Validation item 7 "Using any other method of confirmation which has at 
> least the same level of assurance as those methods previously 
> described" with a specific list of the approved domain validation 
> methods (including new methods proposed by Members). This ballot also 
> tightens up and clarifies the existing Domain Validation methods 1 
> through 6. This revised BR 3.2.2.4 describes the methods that CAs may 
> use to confirm domain ownership or control. Other validation methods 
> can be added in the future.
>
> The Validation Working Group believes the domain validation rules 
> should follow the current BR 3.2.2.4 structure as much as possible so 
> the changes are easy to understand, be worded as simply and clearly as 
> possible so as to be easily implemented by CAs worldwide, and should 
> avoid unnecessary complications or additional requirements that don’t 
> address a realistic security threat. If a Forum Member believes that 
> any new requirements to these validation methods should be added, the 
> Validation Working Group would prefer that the new requirements be 
> proposed and discussed by separate ballot.
>
> Attached is a redlined version of the Baseline Requirements and an 
> explanatory table.
>
> *--Motion Begins-- *
>
> Effective date: Prior to 1 March 2017, CAs may use either the domain 
> validation methods of BR 3.2.2.4 as they existed before this ballot 
> was approved, or the domain validation methods as specified in this 
> ballot (as they may subsequently be further amended), or both. 
> Effective 1 March 2017, CAs may use only the domain validation methods 
> of BR 3.2.2.4 as specified in this ballot (or as such methods may 
> subsequently be further amended).
>
> *Part A.*In Section 1.6.1 of the Baseline Requirements INSERT the 
> following definitions alphabetically:
>
> *Authorization Domain Name:*The Domain Name used to obtain 
> authorization for certificate issuance for a given FQDN. The CA may 
> use the FQDN returned from a DNS CNAME lookup as the FQDN for the 
> purposes of domain validation. If the FQDN contains a wildcard 
> character, then the CA MUST remove all wildcard labels from the left 
> most portion of requested FQDN. The CA may prune zero or more labels 
> from left to right until encountering a Base Domain Name and may use 
> any one of the intermediate values for the purpose of domain validation.
>
> *Authorized Port:*One of the following ports: 80 (http), 443 (http), 
> 115 (sftp), 25 (smtp), 22 (ssh).
>
> *Base Domain Name:*The portion of an applied-for FQDN that is the 
> first domain name node left of a registry-controlled or public suffix 
> plus the registry-controlled or public suffix (e.g. "example.co.uk" or 
> "example.com").   For FQDNs where the right-most domain name node is a 
> gTLD having ICANN Specification 13 in its registry agreement, the gTLD 
> itself may be used as the Base Domain Name.
>
> *Domain Contact:*The Domain Name Registrant, technical contact, or 
> administrative contract (or the equivalent under a ccTLD) as listed in 
> the WHOIS record of the Base Domain Name or in a DNS SOA record.
>
> *Random Value:*A value specified by a CA to the Applicant that 
> exhibits at least 112 bits of entropy.
>
> *Request Token:*A value derived in a method specified by the CA which 
> binds this demonstration of control to the certificate request.
>
> The Request Token SHALL incorporate the key used in the certificate 
> request.
>
> A Request Token MAY include a timestamp to indicate when it was created.
>
> A Request Token MAY include other information to ensure its uniqueness.
>
> A Request Token that includes a timestamp SHALL remain valid for no 
> more than 30 days from the time of creation.
>
> A Request Token that includes a timestamp SHALL be treated as invalid 
> if its timestamp is in the future.
>
> A Request Token that does not include a timestamp is valid for a 
> single use and the CA SHALL NOT re-use it for a subsequent validation.
>
> The binding SHALL use a digital signature algorithm or a cryptographic 
> hash algorithm at least as strong as that to be used in signing the 
> certificate request.
>
> *Required Website Content:*Either a Random Value or a Request Token, 
> together with additional information that uniquely identifies the 
> Subscriber, as specified by the CA.
>
> *Test Certificate:*A Certificate with a maximum validity period of 30 
> days and which: (i) includes a critical extension with the specified 
> Test Certificate CABF OID, or (ii) is issued under a CA where there 
> are no certificate paths/chains to a root certificate subject to these 
> Requirements.
>
> *Part B.*DELETE Section 3.2.2.4 of the Baseline Requirements in its 
> entirety and INSERT the following:
>
> *3.2.2.4 Validation of Domain Authorization or Control*
>
> This section defines the permitted processes and procedures for 
> validating the Applicant's ownership or control of the domain.
>
> The CA SHALL confirm that, as of the date the Certificate issues, 
> either the CA or a Delegated Third Party has validated each 
> Fully-Qualified Domain Name (FQDN) listed in the Certificate using at 
> least one of the methods listed below.
>
> Completed confirmations of Applicant authority may be valid for the 
> issuance of multiple certificates over time. In all cases, the 
> confirmation must have been initiated within the time period specified 
> in the relevant requirement (such as Section 3.3.1 of this document) 
> prior to certificate issuance. For purposes of domain validation, the 
> term Applicant includes the Applicant's Parent Company, Subsidiary 
> Company, or Affiliate.
>
> Note: FQDNs may be listed in Subscriber Certificates using dNSNames in 
> the subjectAltName extension or in Subordinate CA Certificates via 
> dNSNames in permittedSubtrees within the Name Constraints extension.
>
> *3.2.2.4.1 Validating the Applicant as a Domain Contact*
>
> Confirming the Applicant's control over the FQDN by validating the 
> Applicant is the Domain Contact directly with the Domain Name 
> Registrar. This method may only be used if:
>
>  1. The CA authenticates the Applicant's identity under BR Section
>     3.2.2.1 and the authority of the Applicant Representative under BR
>     Section 3.2.5, OR
>  2. The CA authenticates the Applicant's identity under EV Guidelines
>     Section 11.2 and the agency of the Certificate Approver under EV
>     Guidelines Section 11.8; OR
>  3. The CA is also the Domain Name Registrar, or an Affiliate of the
>     Registrar, of the Base Domain Name.
>
> *3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact*
>
> Confirming the Applicant's control over the FQDN by sending a Random 
> Value via email, fax, SMS, or postal mail and then receiving a 
> confirming response utilizing the Random Value. The Random Value MUST 
> be sent to an email address, fax/SMS number, or postal mail address 
> identified as a Domain Contact.
>
> Each email, fax, SMS, or postal mail MAY confirm control of multiple 
> Authorization Domain Names.
>
> The CA or Delegated Third Party MAY send the email, fax, SMS, or 
> postal mail identified under this section to more than one recipient 
> provided that every recipient is identified by the Domain Name 
> Registrar as representing the Domain Name Registrant for every FQDN 
> being verified using the email, fax, SMS, or postal mail.
>
> The Random Value SHALL be unique in each email, fax, SMS, or postal mail.
>
> The CA or Delegated Third Party MAY resend the email, fax, SMS, or 
> postal mail in its entirety, including re-use of the Random Value, 
> provided that the communication's entire contents and recipient(s) 
> remain unchanged.
>
> The Random Value SHALL remain valid for use in a confirming response 
> for no more than 30 days from its creation. The CPS MAY specify a 
> shorter validity period for Random Values, in which case the CA MUST 
> follow its CPS.
>
> *3.2.2.4.3 Phone Contact with Domain Contact*
>
> Confirming the Applicant's control over the requested FQDN by calling 
> the Domain Name Registrant's phone number and obtaining a response 
> confirming the Applicant's request for validation of the FQDN. The CA 
> or Delegated Third Party MUST place the call to a phone number 
> identified by the Domain Name Registrar as the Domain Contact.
>
> Each phone call SHALL be made to a single number and MAY confirm 
> control of multiple FQDNs, provided that the phone number is 
> identified by the Domain Registrar as a valid contact method for every 
> Base Domain Name being verified using the phone call.
>
> *3.2.2.4.4 Constructed Email to Domain Contact*
>
> Confirming the Applicant's control over the requested FQDN by (i) 
> sending an email to one or more addresses created by using 'admin', 
> 'administrator', 'webmaster', 'hostmaster', or 'postmaster' as the 
> local part, followed by the at-sign ("@"), followed by an 
> Authorization Domain Name, (ii) including a Random Value in the email, 
> and (iii) receiving a confirming response utilizing the Random Value.
>
> Each email MAY confirm control of multiple FQDNs, provided the 
> Authorization Domain Name used in the email is an Authorization Domain 
> Name for each FQDN being confirmed
>
> The Random Value SHALL be unique in each email.
>
> The email MAY be re-sent in its entirety, including the re-use of the 
> Random Value, provided that its entire contents and recipient SHALL 
> remain unchanged.
>
> The Random Value SHALL remain valid for use in a confirming response 
> for no more than 30 days from its creation. The CPS MAY specify a 
> shorter validity period for Random Values, in which case the CA.
>
> *3.2.2.4.5 Domain Authorization Document*
>
> Confirming the Applicant's control over the requested FQDN by relying 
> upon the attestation to the authority of the Applicant to request a 
> Certificate contained in a Domain Authorization Document. The Domain 
> Authorization Document MUST substantiate that the communication came 
> from the Domain Contact. The CA MUST verify that the Domain 
> Authorization Document was either (i) dated on or after the date of 
> the domain validation request or (ii) that the WHOIS data has not 
> materially changed since a previously provided Domain Authorization 
> Document for the Domain Name Space.
>
> *3.2.2.4.6 Agreed-Upon Change to Website*
>
> Confirming the Applicant's control over the requested FQDN by 
> confirming one of the following under the 
> "/.well-known/pki-validation" directory, or another path registered 
> with IANA for the purpose of Domain Validation, on the Authorization 
> Domain Name that is accessible by the CA via HTTP/HTTPS over an 
> Authorized Port:
>
>  1. The presence of Required Website Content contained in the content
>     of a file or on a web page in the form of a meta tag. The entire
>     Required Website Content MUST NOT appear in the request used to
>     retrieve the file or web page, or
>  2. The presence of the Request Token or Request Value contained in
>     the content of a file or on a webpage in the form of a meta tag
>     where the Request Token or Random Value MUST NOT appear in the
>     request.
>
> If a Random Value is used, the CA or Delegated Third Party SHALL 
> provide a Random Value unique to the certificate request and SHALL not 
> use the Random Value after the longer of (i) 30 days or (ii) if the 
> Applicant submitted the certificate request, the timeframe permitted 
> for reuse of validated information relevant to the certificate (such 
> as in Section 3.3.1 of these Guidelines or Section 11.14.3 of the EV 
> Guidelines).
>
> Note: Examples of Request Tokens include, but are not limited to: (i) 
> a hash of the public key; (ii) a hash of the Subject Public Key Info 
> [X.509]; and (iii) a hash of a PKCS#10 CSR. A Request Token may also 
> be concatenated with a timestamp or other data. If a CA wanted to 
> always use a hash of a PKCS#10 CSR as a Request Token and did not want 
> to incorporate a timestamp and did want to allow certificate key 
> re-use then the applicant might use the challenge password in the 
> creation of a CSR with OpenSSL to ensure uniqueness even if the 
> subject and key are identical between subsequent requests. This 
> simplistic shell command produces a Request Token which has a 
> timestamp and a hash of a CSR. E.g. echo date -u +%Y%m%d%H%M sha256sum 
> <r2.csr | sed "s/[ -]//g" The script outputs: 
> 201602251811c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f 
> The CA should define in its CPS (or in a document referenced from the 
> CPS) the format of Request Tokens it accepts.
>
> *3.2.2.4.7 DNS Change*
>
> Confirming the Applicant's control over the requested FQDN by 
> confirming the presence of a Random Value or Request Token in a DNS 
> TXT or CAA record for an Authorization Domain Name or an Authorization 
> Domain Name that is prefixed with a label that begins with an 
> underscore character.
>
> If a Random Value is used, the CA or Delegated Third Party SHALL 
> provide a Random Value unique to the certificate request and SHALL not 
> use the Random Value after (i) 30 days or (ii) if the Applicant 
> submitted the certificate request, the timeframe permitted for reuse 
> of validated information relevant to the certificate (such as in 
> Section 3.3.1 of these Guidelines or Section 11.14.3 of the EV 
> Guidelines).
>
> *3.2.2.4.8 IP Address*
>
> Confirming the Applicant's control over the requested FQDN by 
> confirming that the Applicant controls an IP address returned from a 
> DNS lookup for A or AAAA records for the FQDN in accordance with 
> section 3.2.2.5.
>
> *3.2.2.4.9 Test Certificate*
>
> Confirming the Applicant's control over the requested FQDN by 
> confirming the presence of a non-expired Test Certificate issued by 
> the CA on the Authorization Domain Name and which is accessible by the 
> CA via TLS over an Authorized Port for the purpose of issuing a 
> Certificate with the same Public Key as in the Test Certificate.
>
> *3.2.2.4.10. TLS Using a Random Number*
>
> Confirming the Applicant's control over the requested FQDN by 
> confirming the presence of a Random Value within a Certificate on the 
> Authorization Domain Name which is accessible by the CA via TLS over 
> an Authorized Port.
>
> *--Motion Ends—*
>
> The review period for this ballot shall commence immediately and close 
> at 2200 UTC on Friday, 29 July 2016. Unless the motion is withdrawn 
> during the review period, the voting period will start immediately 
> thereafter and will close at 2200 UTC on Friday, 5 August 2016. 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 ten (10) members– at least ten members must participate in 
> the ballot, either by voting in favor, voting against, or abstaining.
>
>
>
> _______________________________________________
> 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/20160805/9ffe7d24/attachment-0003.html>