[cabfpub] Preballot - Revised Ballot 190

Wed May 17 17:04:30 UTC 2017

Doug,

I totally appreciate that sentiment, but you realize one area of the
concern and issues has been the proposal - made by Kirk, Gerv, and Jeremy -
to allow the reuse of insecurely-validated domain names. This seems a
reasonable and appropriate signal that if we're going to permit this -
which I would again stress that I do not believe is permitted under the
current Baseline Requirements - we should at least appropriately indicate
to Relying Parties whether or not they were appropriately validated.

I can understand that some CAs have been engaged in insecure practices,
particularly those whose system designs around security audits prevent
machine readability (which would normally be "Security 101" in any
organization who is concerned about risk), but I do want to make sure we
appropriately indicate to relying parties whether or not the certificates
are properly validated. This provides a reasonable, easily implementable,
intermediate-step to ensure that as the Baseline Requirements permit the
insecure, otherwise forbidden practice, those CAs that have implemented
reliable and secure methods can be appropriately communicated to relying
parties.

I would think CAs that are engaged in secure practices - that is, where
even their reuse of information is consistent with the substantial reforms
made, because these organizations carefully thought about security and
ensured their systems were robust - would be supportive of ways to signal
their improved, robust security to the users, to differentiate from those
certificates whose issuance practices are questionable, at best.

On Wed, May 17, 2017 at 12:56 PM, Doug Beattie <doug.beattie at globalsign.com>
wrote:

> I think we should focus on the core changes to remove “any other method”
> before we start adding more changes to indicate the version of the BRs that
> were used, so I would recommend not including this in ballot 190.  We have
> enough discussion points now, especially if we’re considering anything in
> Jeremy’s latest proposal.
>
>
>
> Doug
>
>
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] *On Behalf Of *Ryan
> Sleevi via Public
> *Sent:* Wednesday, May 17, 2017 12:25 PM
> *To:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Cc:* Ryan Sleevi <sleevi at google.com>
> *Subject:* Re: [cabfpub] Preballot - Revised Ballot 190
>
>
>
> 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:
> 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
> 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/f6c64c2f/attachment-0003.html>