CA/Browser Forum
Home » All CA/Browser Forum Posts » Ballot 74 – Updates to Domain and IP Validation, High Risk Requests, and Data Source in the Baseline Requirements

Ballot 74 – Updates to Domain and IP Validation, High Risk Requests, and Data Source in the Baseline Requirements

Ballot 74 – Updates to Domain and IP Validation, High Risk Requests, and Data Source in the Baseline Requirements (Quorum not met)

Motion

Jeremy Rowley made the following motion, and Dean Coclin and Richard Smith endorsed it:

… Motion begins….

Effective immediately.

Erratum begins

A. Replace the definition of “Domain Authorization” in Section 4 of the Baseline Requirements with the following:

Domain Authorization Document: Documentation provided by, or a CA’s documentation of a communication with, a Domain Name Registrar, the Domain Name Registrant, or the person or entity listed in WHOIS as the Domain Name Registrant (including any private, anonymous, or proxy registration service) attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace.

B. Add the following new definitions to Section 4 of the Baseline Requirements:

High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk-mitigation criteria.

Reliable Data Source: An identification document or source of data used to verify Subject Identity Information that is generally recognized among commercial enterprises and governments as reliable, and which was created by a third party for a purpose other than the Applicant obtaining a Certificate.”

C. Replace Section 11.1 of the Baseline Requirements with the following:

11.1.1 Authorization by Domain Name Registrant

For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant either is the Domain Name Registrant or has control over the FQDN by:

  1. Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar;

  2. Communicating directly with the Domain Name Registrant using an address, email, or telephone number provided by the Domain Name Registrar;

  3. Communicating directly with the Domain Name Registrant using the contact information listed in the WHOIS record’s “registrant”, “technical”, or “administrative” field;

  4. Communicating with the Domain’s administrator using an email address created by pre-pending ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in the local part, followed by the at-sign (“@”), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN;

  5. Relying upon a Domain Authorization Document;

  6. Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN; or

  7. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described.

Note: For purposes of determining the appropriate domain name level or Domain Namespace, the registerable Domain Name is the second-level domain for generic top-level domains (gTLD) such as .com, .net, or .org, or, if the Fully Qualified Domain Name contains a 2 letter Country Code Top-Level Domain (ccTLD), then the domain level is whatever is allowed for registration according to the rules of that ccTLD.

If the CA relies upon a Domain Authorization Document to confirm the Applicant’s control over a FQDN, then the Domain Authorization Document MUST substantiate that the communication came from either the Domain Name Registrant (including any private, anonymous, or proxy registration service) or the Domain Name Registrar listed in the WHOIS. The CA MUST verify that the Domain Authorization Document was either (i) dated on or after the certificate request date or (ii) used by the CA to verify a previously issued certificate and that the Domain Name’s WHOIS record has not been modified since the previous certificate’s issuance.

11.1.2 Authorization for an IP Address

For each IP Address listed in a Certificate, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant has control over the IP Address by:

  1. Having the Applicant demonstrate practical control over the IP Address by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the IP Address;

  2. Obtaining documentation of IP address assignment from the Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC);

  3. Performing a reverse-IP address lookup and then verifying control over the resulting Domain Name under Section 11.1.1; or

  4. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant has control over the IP Address to at least the same level of assurance as the methods previously described.”

D. Replace Section 11.3 of the Baseline Requirements with the following:

11.3 Age of Certificate Data

Section 9.4 limits the validity period of Subscriber Certificates. The CA MAY use the documents and data provided in Section 11 to verify certificate information, provided that the CA obtained the data or document from a source specified under Section 11 no more than thirty-nine (39) months prior to issuing the certificate.”

E. Replace Section 11.5 of the Baseline Requirements with the following:

11.5 High Risk Requests

The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements.”

F. Replace Section 11.6 of the Baseline Requirements with the following:

11.6 Data Source Accuracy

Prior to using any data source as a Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification. The CA SHOULD consider the following during its evaluation:

  1. The age of the information provided,

  2. The frequency of updates to the information source,

  3. The data provider and purpose of the data collection,

  4. The public accessibility of the data availability, and

  5. the relative difficulty in falsifying or altering the data.

Databases maintained by the CA, its owner, or its affiliated companies do not qualify as a Reliable Data Source if the primary purpose of the database is to collect information for the purpose of fulfilling the validation requirements under Section 11.

G. Replace Section 14.2.1 of the Baseline Requirements with the following:

14.2.1 General

The CA MAY delegate the performance of all, or any part, of Section 11 of these Requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 11. Before the CA authorizes a Delegated Third Party to perform a delegated function, the CA SHALL contractually require the Delegated Third Party to:

  1. Meet the qualification requirements of Section 14.1, when applicable to the delegated function;

  2. Retain documentation in accordance with Section 15.3.2;

  3. Abide by the other provisions of these Requirements that are applicable to the delegated function; and

  4. Comply with (a) the CA’s Certificate Policy/Certification Practice Statement or (b) the Delegated Third Party’s practice statement that the CA has verified complies with these Requirements.

The CA SHALL verify that the Delegated Third Party’s personnel involved in the issuance of a Certificate meet the training and skills requirements of Section 14 and the document retention and event logging requirements of Section 15.

If a Delegated Third Party fulfills any of the CA’s obligations under Section 11.5 (High Risk Requests), the CA SHALL verify that the process used by the Delegated Third Party to identify and further verify High Risk Certificate Requests provides at least the same level of assurance as the CA’s own processes.”

H. Replace Section 11.2.1 of the Baseline Requirements with the following:

11.2.1 Identity

If the Subject Identity Information is to include the name or address of an organization, the CA SHALL verify the identity and address of the organization and that the address is the Applicant’s address of existence or operation.

The CA SHALL verify the identity and address of the Applicant using documentation provided by, or through communication with, at least one of the following:

  1. A government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition;

  2. A third party database that is periodically updated and considered a Reliable Data Source;

  3. A site visit by the CA or a third party who is acting as an agent for the CA; or

  4. An Attestation Letter.

The CA MAY use the same documentation or communication described in 1 through 4 above to verify both the Applicant’s identity and address.

Alternatively, the CA MAY verify the address of the Applicant (but not the identity of the Applicant) using a utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.”

I. Replace Section 11.2.2 of the Baseline Requirements with the following:

11.2.2 DBA/Tradename

If the Subject Identity Information is to include a DBA or tradename, the CA SHALL verify the Applicant’s right to use the DBA/tradename using at least one of the following:

  1. Documentation provided by, or communication with, a government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition;

  2. A Reliable Data Source;

  3. Communication with a government agency responsible for the management of such DBAs or tradenames;

  4. An Attestation Letter accompanied by reliable documentary support; or

  5. A utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.”

J. Replace Section 11.2.4 of the Baseline Requirements with the following:

11.2.4 Verification of Individual Applicant

If an Applicant subject to this Section 11.2 is a natural person, then the CA SHALL verify the Applicant’s name, Applicant’s address, and the authenticity of the certificate request.

The CA SHALL verify the Applicant’s name using a legible copy, which discernibly shows the Applicant’s face, of at least one currently valid government-issued photo ID (passport, drivers license, military ID, national ID, or equivalent document type). The CA SHALL inspect the copy for any indication of alteration or falsification.

The CA SHALL verify the Applicant’s address using a form of identification that the CA determines to be reliable, such as a government ID, utility bill, or bank or credit card statement. The CA MAY rely on the same government-issued ID that was used to verify the Applicant’s name.

The CA SHALL verify the certificate request with the Applicant using a Reliable Method of Communication.”

Erratum ends

The ballot review period comes into effect at 21:00 UTC on 17 May 2012 and will close at 21:00 UTC on 24 May 2012. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 21:00 UTC on 31 May 2012. Votes must be cast by “reply all” to this email.

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.

Motion ends

Latest releases
Code Signing Requirements
v3.8 - Aug 5, 2024

What’s Changed CSC-25: Import EV Guidelines to CS Baseline Requirements by @dzacharo in https://github.com/cabforum/code-signing/pull/38 Full Changelog: https://github.com/cabforum/code-signing/compare/v3.7...v3.8

S/MIME Requirements
v1.0.6 - Ballot SMC08 - Aug 29, 2024

This ballot sets a date by which issuance of certificates following the Legacy generation profiles must cease. It also includes the following minor updates: Pins the domain validation procedures to v 2.0.5 of the TLS Baseline Requirements while the ballot activity for multi-perspective validation is concluded, and the SMCWG determines its corresponding course of action; Updates the reference for SmtpUTF8Mailbox from RFC 8398 to RFC 9598; and Small text corrections in the Reference section

Network and Certificate System Security Requirements
v2.0 - Ballot NS-003 - Jun 26, 2024

Ballot NS-003: Restructure the NCSSRs in https://github.com/cabforum/netsec/pull/35

Edit this page
The Certification Authority Browser Forum (CA/Browser Forum) is a voluntary gathering of Certificate Issuers and suppliers of Internet browser software and other applications that use certificates (Certificate Consumers).