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

Dean Coclin Dean_Coclin at symantec.com
Sun Jan 8 17:04:49 MST 2017


Kirk,

Thank you for providing this detailed summary. It really helps explain
things well.

 

One slight correction to this statement: "We don't know, as we have never
created a PAG before.  The PAG will start its work soon."

 

Actually we did create a PAG before (you were a member). See enclosed.
Perhaps you meant we never created a PAG to do the work scheduled for this
PAG.


Dean

 

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Kirk Hall via
Public
Sent: Sunday, January 08, 2017 6:21 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Kirk Hall <Kirk.Hall at entrustdatacard.com>
Subject: [cabfpub] Recap of Ballot 180, 181, and 182 results, and next steps

 

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/20170109/8d5d5afa/attachment-0001.html>
-------------- next part --------------
An embedded message was scrubbed...
From: "Dean Coclin" <Dean_Coclin at symantec.com>
Subject: [cabfpub] Call for PAG members
Date: Thu, 9 Jul 2015 20:21:26 -0500
Size: 25123
URL: <http://cabforum.org/pipermail/public/attachments/20170109/8d5d5afa/attachment-0001.mht>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5723 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20170109/8d5d5afa/attachment-0001.bin>


More information about the Public mailing list