[cabfpub] Ballot 182 – Readopting BR 3.2.2.4 (Part 2)

[Ryan Sleevi]

Last request for a redline version. Thanks :)

On Tue, Oct 25, 2016 at 1:38 PM, Kirk Hall via Public <public at cabforum.org>
wrote:

> *This is the start of the 7 day discussion period for this Ballot.  The
> Review Period under our IPR Policy will start on Nov. 1, and run for 60
> days.  I will send out a formal Review Notice with Draft Guidelines on Nov.
> 1 with a template form of Exclusion Notice that Members may use.*
>
>
>
>
>
> *Ballot 182 – Readopting BR 3.2.2.4 (Part 2)*
>
>
>
> The following motion has been proposed by Kirk Hall of Entrust and
> endorsed by Peter Bowen of Amazon and Virginia Fournier of Apple as a Final
> Guideline:
>
>
>
> -- MOTION BEGINS –
>
>
>
> In accordance with the Bylaws and Intellectual Property Rights (IPR)
> Policy of the CA/Browser Forum (the “Forum”), the Forum Baseline
> Requirements (BR) and Extended Validation Guidelines (EVGL), as previously
> approved by all ballots up to and including Ballot 176, are hereby
> readopted by this Ballot, with the following amendments.
>
>
>
> 11.  BR 3.2.2.4 is amended to read in its entirety 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 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 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.
>
>
>
> *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.
>
>
>
> *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.
>
>
>
> *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.
>
>
>
> *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: 201602251811c9c863405fe7675a39
> 88b97664ea6baf442019e4e52fa335f406f7c5f26cf14f 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 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 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).
>
>
>
> *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.
>
>
>
> *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.
>
>
>
> *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.
>
>
>
> In the event that this Ballot and Ballot 181 are both approved by the
> Forum, the provisions of this Ballot shall supersede and replace any
> conflicting provisions of Ballot 181.
>
>
>
> The proposer and endorsers of this Ballot may withdraw this Ballot at any
> time prior to completion of the final vote for approval, in which case the
> Ballot will not proceed further.
>
>
>
> *-- MOTION ENDS – *
>
>
>
> The procedure for this Maintenance Guideline ballot is as follows (exact
> start and end times may be adjusted to comply with applicable Bylaws and
> IPR Agreement):
>
>
>
> BALLOT 182
>
> Status: Final Guideline
>
> Start time (22:00 UTC)
>
> End time (22:00 UTC)
>
> Discussion (7 days)
>
> Oct. 25, 2016
>
> Nov. 1, 2016
>
> Review Period (Chair to send Review Notice) (60 days).
>
> If Exclusion Notice(s) filed, PAG to be created and no further action
> until PAG recommendations received.
>
> If no Exclusion Notice(s) filed, proceed to:
>
> Nov. 1, 2016
>
> Dec. 31, 2016
>
> Vote for approval (7 days)
>
> Dec. 31, 2016
>
> Jan. 7, 2017
>
>
>
> 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 currently
> ten (10) members – at least ten members must participate in the ballot,
> either by voting in favor, voting against, or abstaining.
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20161025/2dff54fb/attachment-0001.html>