[cabfpub] Preballot - Revised Ballot 190

[Ryan Sleevi]

The linked thread discusses that, with the conclusion that simply omitting
the validation method entirely - that is, just noting the 'conforming'
version, as in "Everything in this certificate, if it was issued without
any reused information, would conform with version X of the BRs". That's
how we got into the policy OID discussion :)

So yes, it's still quite simple :)

On Wed, May 17, 2017 at 1:15 PM, Erwann Abalea <Erwann.Abalea at docusign.com>
wrote:

> Bonsoir,
>
> Replying late on this subject.
> The new extension proposal is incomplete, in my view, as it provides
> enough space to specify only 1 validation method, when a certificate can
> contain several FQDNs with potentially different methods used to validate
> them.
> Turn that into a SEQUENCE OF BRComplianceDetails, and you’ll need to add
> some language about ordering of the SAN extension and this new one, and
> voilà, it doesn’t minimizes at all changes to the CA infrastructure.
>
> Cordialement,
> Erwann Abalea
>
> Le 17 mai 2017 à 18:24, Ryan Sleevi via Public <public at cabforum.org> a
> écrit :
>
> 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 <
> public at cabforum.org> 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:201602251811c9c863405fe7675a3988b97664ea6baf442019e4
>> e52fa335f406f7c5f26cf14f
>>
>> 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
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
>>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170517/024534e0/attachment-0003.html>