Kirk, I didn't see an answer to this question posed - https://cabforum.org/pipermail/public/2017-April/010802.html
For example, proposed technical details were provided in https://cabforum.org/pipermail/public/2017-May/010848.html Would you (and Jeremy and Gerv) be receptive to including this in 3.2.2.4? I'd be happy to write the text to accomplish this, but I was under the misunderstanding that the lack of reply meant y'all were considering it. There did not appear to be any objections raised on the list - simply a discussion related to policy OIDs versus an extension, but the the extension provides a semantically valid approach that minimizes any changes to CA infrastructure. On Wed, May 17, 2017 at 12:17 PM, Kirk Hall via Public <[email protected]> wrote: > Jeremy, Gerv, and I have worked on this revised version of Ballot 190, and > offer it for comment as a preballot. > > A few points to highlight. > > - There is now a new fifth paragraph in the introductory part of > BR 3.2.2.4 that requires CAs to maintain a record of which domain > validation method they use (including version number) for each validated > domain. This is to add more flexibility in the future if methods must be > changed and existing domains revalidated for some reason. > > - The new sixth paragraph clarifies that domains validated prior > to the effective date of Ballot 190 are not required to be revalidated, but > the validation data can be reused for the periods specified in BR 4.2.1 and > EVGL 11.14.3. > > - We also have added a line to each validation method indicating > whether or not the validation method is suitable for wildcard certificates. > > I will try to create and circulate a “show changes” version of BR 3.2.2.4 > that shows all these changes against the current language. > > *** > > *Ballot 190 - Revised Validation Requirements* > > *Purpose of Ballot:* The purpose of this ballot is to 1) re-introduce the > BR 3.2.2.4 domain validation methods removed in ballot 180-182 because of > IPR concerns, 2) clarify some issues with the .well-known method, 3) > specify how the reuse of information works with respect to the newly > adopted methods, and (4) indicate which domain validation methods are > suitable for wildcard certificates. > > The following motion has been proposed by Jeremy Rowley of DigiCert and > endorsed by the following CA/B Forum member representatives: Chris Bailey > of Entrust Datacard and YYYY to introduce new Final Maintenance Guidelines > for the "Baseline Requirements Certificate Policy for the Issuance and > Management of Publicly-Trusted Certificates" (Baseline Requirements). > > *--Motion Begins--* > > *Ballot Section 1* > > 1) The introductory paragraphs to BR 3.2.2.4 are amended as follows: > > *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 4.2.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. > > CAs SHALL maintain a record of which domain validation method, including > relevant BR version number, they used to validate every domain. > > After *[insert effective date of Ballot 190],* a CA MAY continue to reuse > validation data from its validation of an FQDN under the methods listed in > (a) BR 4.3.3.2 of Version 1.3.7 (or earlier) of the Baseline Requirements, > (b) BR 4.3.3.2 of Version 1.3.8 to 1.4.1 of the Baseline Requirements, or > (c) BR 3.2.2.4 of Version 1.4.2 to 1.4.x *[insert most recent version > number for the BRs at time this ballot becomes effective] *of the > Baseline Requirements for the periods specified in BR 4.2.1 or the EVGL > 11.14.3. > > 2) Replace Section 3.2.2.4.1: > > *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. > > *Note*: This method is suitable for validating domains for wildcard > issuance. > > 3) Replace Section 3.2.2.4.2: > > *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. > > *Note*: This method is suitable for validating domains for wildcard > issuance. > > 4) Replace Section 3.2.2.4.3: > > *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. > > *Note*: This method is suitable for validating domains for wildcard > issuance. > > 5) Replace Section 3.2.2.4.4: > > *3.2.2.4.4 Constructed Email to Domain Contact* > > Confirm 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. > > *Note*: This method is suitable for validating domains for wildcard > issuance. > > 6) Add the following to the end of Section 3.2.2.4.5: > > *Note*: This method is suitable for validating domains for wildcard > issuance. > > 7) Edit Section 3.2.2.4.6: > > *3.2.2.4.6 Agreed-Upon Change to Website* > > Confirming the Applicant's control over the requested FQDN by confirming *the > presence of a Request Token or Random Value contained in the content of a > file or on a web page in the form of a meta tag* 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*. > The Request Token or Random Value MUST NOT appear in the request for the > file or web-page. * : > > 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: > 201602251811c9c863405fe7675a3988b97664ea6baf442019e4e52fa335 > f406f7c5f26cf14f > > The CA should define in its CPS (or in a document referenced from the CPS) > the format of Request Tokens it accepts. > > *Note*: This method is suitable for validating domains for wildcard > issuance. > > 8) Add Section 3.2.2.4.7: > > *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 *CNAME,* 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). > > *Note*: This method is suitable for validating domains for wildcard > issuance. > > 9) Add Section 3.2.2.4.8: > > *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. > > *Note*: This method is NOT suitable for validating domains for wildcard > issuance. > > 10) Add Section 3.2.2.4.9: > > *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. > > *Note*: This method is suitable for validating domains for wildcard > issuance. > > 11) Add the following to the end of Section 3.2.2.4.10: > > *Note*: This method is suitable for validating domains for wildcard > issuance. > > 12) Delete Section 3.2.2.4.11 > > 13) Delete the definition of “Required Website Content” > > 14) Revised the definition of “Authorized Ports” as follows: > > One of the following ports: 80 (http), 443 (http), 115 (sftp), 25 (smtp), > 22 (ssh). > > 15) Revise the definition of Test Certificate as follows: > > *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 *(2.23.140.2.1)*, or (ii) is issued under a CA where > there are no certificate paths/chains to a root certificate subject to > these Requirements > > *--Motion Ends--* > > The procedure for approval of this Final Maintenance Guideline ballot is > as follows (exact start and end times may be adjusted to comply with > applicable Bylaws and IPR Agreement): > > > > BALLOT 190 > > Status: Final Maintenance Guideline > > Start time (23:00 UTC) > > End time (23:00 UTC) > > Discussion (7 to 14 days) > > > > > > Vote for approval (7 days) > > > > > > If vote approves ballot: Review Period (Chair to send Review Notice) (30 > days). > > If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be > created. > > If no Exclusion Notices filed, ballot becomes effective at end of Review > Period. > > Upon filing of Review Notice by Chair > > 30 days after filing of Review Notice by Chair > > > > From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final > Maintenance Guideline, such ballot will include a redline or comparison > showing the set of changes from the Final Guideline section(s) intended to > become a Final Maintenance Guideline, and need not include a copy of the > full set of guidelines. Such redline or comparison shall be made against > the Final Guideline section(s) as they exist at the time a ballot is > proposed, and need not take into consideration other ballots that may be > proposed subsequently, except as provided in Bylaw Section 2.3(j). > > > > Votes must be cast by posting an on-list reply to this thread on the > Public list. 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/ > > > > 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 shown on > CA/Browser Forum wiki. Under Bylaw 2.2(g), at least the required quorum > number must participate in the ballot for the ballot to be valid, either by > voting in favor, voting against, or abstaining. > > > > > > > > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
