[cabfpub] Recap of Ballot 180, 181, and 182 results, and next steps

Kirk Hall Kirk.Hall at entrustdatacard.com
Sun Jan 8 16:20:48 MST 2017


As mentioned on earlier messages, Ballots 180 and 181 passed, and Ballot 182 failed.  Here is my view of where we are.

What Requirements and Guidelines are in effect now?

Ballot 181 included this provision: "In the event that this Ballot [181] and Ballot 180 are both approved by the Forum, the provisions of this Ballot [181] shall supersede and replace any conflicting provisions of Ballot 180."


Ballots 180 and 181 are attached again.  As you see, we re-adopted all the provisions of the following requirements and guidelines (except for the amendments as noted below) in conformity with our IPR Policy, and we can now safely adopt amendments ("Maintenance Guidelines" to these "Final Guidelines") through new ballots in the future:



*       Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates (BRs)

*       Guidelines for the Issuance and Management of Extended Validation Certificates (EVGL)

*       Guidelines for the Issuance and Management of Extended Validation Code Signing Certificates, and

*       Network and Certificate System Security Requirements,


We did make limited changes in the BRs and EVGL.  Under Ballot 181, BR 3.2.2.4 now reads as follows (effective immediately):

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 [Reserved]

3.2.2.4.2 [Reserved]

3.2.2.4.3 [Reserved]

3.2.2.4.4 [Reserved]

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 [Reserved]

3.2.2.4.8 [Reserved]

3.2.2.4.9 [Reserved]

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.

3.2.2.4.11 Other Methods

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 by using any 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 Fully Qualified Domain Name (FQDN).
Under Ballot 180, EVGL 11.7.1 now reads as follows (effective immediately):

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 rightmost 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 3.2.2.4 of the Baseline Requirements. For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm, 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.

We will generate a new version of the BRs and EVGL very soon to reflect these amendments.

What happened to the other domain verification methods?  What happened to Ballot 169?

You will notice that in Ballot 181 we re-adopted domain validation methods 5, 6, and 10 from Ballot 169.

Methods 1-4, and 7-9 were included in Ballot 182 because they had previously resulted in IP Exclusion Notices, and we expected they would generate Exclusion Notices again - and we wanted to send those validation methods and the IP Exclusion Notice claims to a Patent Advisory Group (PAG) in accordance with our IPR Policy.  Once the Exclusion Notices for Ballot 182 were filed during the IP Review Period, the Members decided not to vote on Ballot 182 and so the Ballot failed.  That means the version of BR 3.2.2.4 in Ballot 181 is the version that has been adopted.

In effect, Ballot 169 has been rescinded and replaced by Ballot 181.  There is no longer a March 1, 2017 deadline to follow Ballot 169.

Does this mean that CAs can only use domain validations methods 5, 6, and 10 under BR 3.2.2.4?

No - in Ballot 181, we also adopted a new Method 11 which is similar to our old method 7 - "any other method".

Here is new Method 11, which is effective immediately - it allows CAs to use "any method of confirmation", but please note the requirement that the CA must maintain "documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the Fully Qualified Domain Name (FQDN)."

3.2.2.4.11 Other Methods

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 by using any 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 Fully Qualified Domain Name (FQDN).

Please note that this new Method 11 is likely only temporary - once the PAG finishes its work, a new Ballot will likely be developed to readopt some version of Methods 1-4, and 7-9 from Ballot 169.  At that point, this new Method 11 will likely be eliminated.

As a "safe harbor", CAs may want to limit themselves to Methods 1-4, and 7-9 from Ballot 169 if they are going to rely on new Method 11 ("any other method") while the work of the PAG goes forward.  However, this is not a requirement of the BRs as they exist today.

What domain validation methods are now permitted for EV certificates?

As you see from revised EVGL 11.7.1 above, the EV Guidelines now require that CAs perform domain validation for EV certificates "using a procedure specified in Section 3.2.2.4 of the Baseline Requirements."  Under the current BRs, that means domain validation Methods 5, 6, 10, and 11.

How long will it take the PAG to complete its work and amend the domain validation methods of BR 3.2.2.4?

We don't know, as we have never created a PAG before.  The PAG will start its work soon.

In this case, several Exclusion Notices were filed by Members, and it may take some weeks or months to evaluate the Exclusion Notices.  The IPR Policy states that the Forum has a goal "to issue Guidelines that can be implemented on a Royalty-Free (RF) basis subject to the conditions of this policy."  The PAG will examine the IP contained in the Exclusion Notices against the domain validation methods in Ballot 182, and where there is a conflict the PAG may then provide conclusions and recommendations to the Forum on how to "resolve any conflicts."

IPR Policy 7.3.2. Possible PAG Conclusions
After appropriate consultation, the PAG may conclude:
a. The initial concern has been resolved, enabling the work on the Guideline to continue.
b. The CAB Forum should be instructed to consider designing around the identified claims.
c. The PAG should seek further information and evaluation, including and not limited to evaluation of the patents in question or the terms under which CAB Forum RF licensing requirements may be met.
d. The project relating to the Draft Guideline in question should be terminated.
e. The Final Guideline or Final Maintenance Guideline should be rescinded.
f. Alternative licensing terms should be considered.

What happens after the PAG completes its work?

We don't know for sure, but the next steps after the PAG's conclusions will likely be guided by the new voting rules we are developing under draft Ballot 183 (see current discussion and the procedures described in draft Ballot 183, including the process flow diagram provided with the draft Ballot).  This Ballot is intended to clarify the interaction between our Ballot voting rules in the Bylaws and the requirements of our IPR Policy.

It is likely a new domain validation procedure Ballot will be drafted after the PAG completes its work to readopt domain validation methods 1-4 and 7-10 in some form, and to delete new Method 11.  That new Ballot will then be subject to a discussion period, vote, IP Review Period, etc. according to whatever new voting rules we may adopt.

What about ballots on other subjects?  Can we proceed now?

Yes, we can proceed with Ballots on other subjects now that we have re-adopted the various requirements and guidelines via Ballots 180 and 181.  A Ballot that only amends our Bylaws can proceed now following our existing Bylaws voting rules (7 days discussion followed by 7 days voting, but no Review Period because no Maintenance Guidelines are affected), and we are trying to get to a vote on new voting rules in Ballot 183 as soon as possible.

It will be best to defer any new ballots on ballots that affect the BRs, EVGL, etc. until after we have clarified our voting rules via Ballot 183.  However, as soon as Ballot 183 (in some form) is adopted, then we can proceed on all the other pending ballots we have in the queue.  With luck, that will happen later this month.


Thanks to everyone for their patience and cooperation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170108/ab1197be/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ballot 180.pdf
Type: application/pdf
Size: 219445 bytes
Desc: Ballot 180.pdf
URL: <http://cabforum.org/pipermail/public/attachments/20170108/ab1197be/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ballot 181.pdf
Type: application/pdf
Size: 212416 bytes
Desc: Ballot 181.pdf
URL: <http://cabforum.org/pipermail/public/attachments/20170108/ab1197be/attachment-0003.pdf>


More information about the Public mailing list