[cabfpub] Ballot 169 - Revised Validation Requirements

[Ben Wilson]

Is there a working group call tomorrow?

 

From: Kirk Hall [mailto:Kirk.Hall at entrust.com] 
Sent: Wednesday, July 27, 2016 7:43 AM
To: Ben Wilson <ben.wilson at digicert.com>; 'CABFPub' <public at cabforum.org>
Subject: RE: Ballot 169 - Revised Validation Requirements

 

Ben, I see you started the ballot period - aren't there some proposals for
amendment?  Should you stop the ballot from proceeding for now so the
proposals can be sorted out?

 

From: public-bounces at cabforum.org <mailto:public-bounces at cabforum.org>
[mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, July 22, 2016 11:07 AM
To: CABFPub <public at cabforum.org <mailto:public at cabforum.org> >
Subject: [cabfpub] Ballot 169 - Revised Validation Requirements

 

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 gTLDs, the domain  <http://www.[gTLD> www.[gTLD] will be
considered to be a Base Domain. 

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) which chains to a root certificate not 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/>
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.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160727/415df405/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4954 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160727/415df405/attachment-0001.p7s>