Amazon votes YES on Ballot 181. > On Jan 4, 2017, at 10:33 AM, Jos Purvis (jopurvis) via Public > <[email protected]> wrote: > > Cisco votes YES. > > > -- > Jos Purvis ([email protected]) <mailto:[email protected])> > _.|._.|._ cisco systems | Cryptographic Services > PGP: 0x89a3b545 / 0x07d19105 | +1 919.991.9114 (desk) > > > >> On 2017-Jan-02, 13:29, "Public on behalf of Kirk Hall via Public" >> <[email protected] <mailto:[email protected]> on behalf >> of [email protected] <mailto:[email protected]>> wrote: >> >> >> >> The voting period for Ballot 181 has started, and will continue until >> January 7, 2017 at 22:00 UTC. The ballot is shown below. Please vote this >> week on this ballot and also on Ballot 180. Voting will occur on the Public >> list. >> >> >> Ballot 181 – Readopting BR 3.2.2.4 (Part 1) >> >> 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. >> >> 1. 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 [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). >> >> In the event that this Ballot and Ballot 180 are both approved by the Forum, >> the provisions of this Ballot shall supersede and replace any conflicting >> provisions of Ballot 180. >> >> 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 181 >> 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/ >> <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 > [email protected] <mailto:[email protected]> > https://cabforum.org/mailman/listinfo/public > <https://cabforum.org/mailman/listinfo/public>
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
