Validating requirements

Rated 4.4/5 based on 783 customer reviews

Voting on Ballot 169, Revised Validation Requirements, has ended.

Here are the results: From the CAs, we received 19 YES votes, 0 NO votes and 0 Abstentions From the Browsers, we received 3 YES votes, 0 NO votes and 0 Abstentions Therefore, the ballot passes unanimously.

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.

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.

This ballot also tightens up and clarifies the existing Domain Validation methods 1 through 6.

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. DELETE Section of the Baseline Requirements in its entirety and INSERT the following: 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.

This ballot has an effective date of March 1, 2017.

CA-Browser Forum BR 1.3.7-redlined w Ballot 169 Ballot 169 – Revised Validation Requirements The following motion has been proposed by Jeremy Rowley of Digi Cert and endorsed by Tim Hollebeek of Trustwave and Doug Beattie of Global Sign: 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).

Leave a Reply