[cabf_validation] Endorsers for removing any other IP method

Mon Jul 9 22:39:51 MST 2018

I added it as proposed method 6 was something used at DigiCert previously for connected devices. The method was discussed on validation working group calls, but I don’t think the method was ever discussed outside of that group. 

From: Validation <validation-bounces at cabforum.org> On Behalf Of Wayne Thayer via Validation
Sent: Monday, July 9, 2018 1:02 PM
To: Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Endorsers for removing any other IP method

Mozilla may also be willing to endorse pending a discussion of #6.

I understand that the intent of this ballot is to replace "any other method" with a specification of everything CAs currently do to validate IP addresses, regardless of the security properties of those methods. Then we'll analyze and improve these methods. However, I am concerned about the new #6. In particular, step 3 is under-specified. Is it intended to require the same validation as method #1? What I want to avoid is making matters worse by publishing a method that is patently insecure and in so doing encouraging [more] CAs to adopt it.

The first reference I was able to find to #6 was in Jeremy's Oct 2017 ballot proposal: https://cabforum.org/pipermail/validation/2017-October/000645.html

- Wayne

On Mon, Jul 9, 2018 at 11:38 AM Ryan Sleevi via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

Also, can you point me to the meeting minutes or mailing list discussion to where "3.2.2.5.6. Delegated Control Over a Device" was described? I'm having trouble finding who described that and why.

On Mon, Jul 9, 2018 at 2:37 PM Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > wrote:

Any chance you've already got a redline made?

In the past "Replace this whole section" has tended to botch the redline, so that's the only hesitation towards endorsing.

On Mon, Jul 9, 2018 at 2:18 PM Tim Hollebeek via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

I know Robin said he’d endorse this ballot.  I remember I had another endorser, but I forgot who it was while waiting … can someone remind me, or is someone else willing to endorse?

-Tim

The following motion has been proposed by Tim Hollebeek of DigiCert and endorsed by Robin Alden of Comodo and ???.

Background: 

Ballot 169 removed Method 11 ("Any Other Method") from 3.2.2.4 and replaced it with explicit validation methods, but it's sibling in 3.2.2.5 item 4 is still in the Baseline Requirements.

This ballot removes 3.2.2.5 item 4 and replaces it with an explicit list of IP validation methods.

The intention is that, moving forward, IP validation methods will be handled in the same way as domain-name validation methods, and CAs that want to use new methods or variants of existing methods must bring them to the Forum for scrutiny, first.

-- MOTION BEGINS -- 

Replace 3.2.2.5, in it's entirety, with the following text:

"3.2.2.5. Authentication for an IP Address

This section defines the permitted processes and procedures for validating the Applicant’s ownership or control of an IP Address listed in the Certificate.

The CA SHALL confirm that prior to issuance the CA verified each IP Address listed in the Certificate using at a method specified in this section 3.2.2.5.

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 IP Address validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate. 

CAs SHALL maintain a record of which domain validation method, including the relevant BR version number, was used to validate each IP address.

Note: IP Addresses are listed in Subscriber Certificates using iPAddress in the subjectAltName extension. CAs are not required to verify IP Addresses listed in Subordinate CA Certificates via iPAddress field in the permittedSubtrees or excludedSubtrees in the Name Constraints extension prior to inclusion in the Subordinate CA Certificate. Inclusion of an IP address in a permittedSubtree or excludedSubtree extension does not limit or meet the requirements to validate each IP address in accordance with this section.

3.2.2.5.1. Agreed-Upon Change to Website

If using this method, the CA SHALL confirm the Applicant's control over the requested IP Address by confirming the presence of a Request Token or Random Value contained in the content of a file or webpage in the form of a meta tag of the following under the "/.well-known/pki-validation" directory, or another path registered with IANA for the purpose of validating control of Domain Names or IP addresses, on the IP Address 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. 

If a Random Value is used, the CA 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 Requirements). 

3.2.2.5.2. Validating the Applicant as the IP Owner

If using this method, the CA SHALL confirm the Applicant’s control over an IP Address by obtaining documentation of IP address assignment to the Applicant directly from the Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC). A CA MAY NOT use this method except unless the CA validates (i) the Applicant's identity under BR Section 3.2.2.1 and (ii) the authority of the Applicant Representative under BR Section 3.2.5.

3.2.2.5.3. Reverse Address Lookup

If using this method, the CA SHALL verify the Applicant’s control over the IP Address by obtaining a Domain Name associated with the IP Address through a reverse-IP lookup on the IP Address and then verifying control over the Domain Name using a method permitted under Section 3.2.2.4.

3.2.2.5.4. Test Certificate

If using this method, the CA SHALL confirm the Applicant's control over the requested IP Address by confirming the presence of a non-expired Test Certificate issued by the CA on the IP Address 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.5.5. TLS Using a Random Number

If using this method, the CA SHALL confirm the Applicant's control over the requested IP Address by confirming the presence of a Random Value within a Certificate on the IP Address which is accessible by the CA via TLS over an Authorized Port.

3.2.2.5.6. Delegated Control Over a Device

If using this method, the CA SHALL verify the Applicant’s control over an IP Address by 1) the CA accessing a device located at the requested IP Address, 2) the CA authenticating to the device using credentials provided by the Applicant or created by the CA, and 3) the CA adding a Request Token or Random Value to a file on the device at a location determined by the CA."

-- MOTION ENDS -- 

The procedure for this ballot is as follows (exact start and end times may be adjusted to comply with applicable Bylaws and IPR Agreement): 

BALLOT 222 Status: Remove "Any Other Method" for IP validation             

                                                            Start time (4:00 pm Eastern)            End time (4:00 pm Eastern) 

Discussion (7+ days)                       2 May 2018                                              not before 9 May 2018 

Vote for approval (7 days)            (Ballot reposted by Proposer)  (Reposted + 7 days) 

If vote approves ballot: 

Review Period                                 (Chair to send Review Notice) (Notice sent + 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.

>From the Bylaws section 2.4(a): "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 Section 2.4(j) below". 

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 the Bylaws section 2.3(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.

_______________________________________________
Validation mailing list
Validation at cabforum.org <mailto:Validation at cabforum.org> 
https://cabforum.org/mailman/listinfo/validation

_______________________________________________
Validation mailing list
Validation at cabforum.org <mailto:Validation at cabforum.org> 
https://cabforum.org/mailman/listinfo/validation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180710/0c17ef23/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4984 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180710/0c17ef23/attachment-0001.p7s>