[Servercert-wg] Ballot SCx: "Remove Any Other Method" for IPs

Fri Aug 17 09:12:32 MST 2018

Tim,

I'd like to endorse.

From: Tim Hollebeek <tim.hollebeek at digicert.com> 
Sent: Friday, August 17, 2018 10:23 AM
To: Doug Beattie <doug.beattie at globalsign.com>; CA/Browser Forum Public
Discussion List <public at cabforum.org>; CA/B Forum Server Certificate WG
Public Discussion List <servercert-wg at cabforum.org>
Subject: RE: Ballot SCx: "Remove Any Other Method" for IPs

And yes, I was thinking of deleting 4 and 5.  I thought I'd just recirculate
the existing ballot to get endorsers first since this is a new WG .

-Tim

From: Doug Beattie <doug.beattie at globalsign.com> 
Sent: Friday, August 17, 2018 9:41 AM
To: Tim Hollebeek <tim.hollebeek at digicert.com>; CA/Browser Forum Public
Discussion List <public at cabforum.org>; CA/B Forum Server Certificate WG
Public Discussion List <servercert-wg at cabforum.org>
Subject: RE: Ballot SCx: "Remove Any Other Method" for IPs

Tim,

I have a few suggestions on this:

1) Regarding IP address validation method 1: The Domain Validation Method
3.2.2.4.1 has been retired, so we should not base new methods on this.
Instead of describing this as verifying that the applicant is assigned as
the owner, shouldn't we take the contact data from that repository and do an
email, phone, SMS, Postal challenge with a random number?  I'd recommend we
split this out into 2 methods that parallel the Domain Validation methods:

-          3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact

-          3.2.2.4.3 Phone Contact with Domain Contact

2) The description of method 2 (web site change) is old and we should use
the current BR method 3.2.2.4.6 as the basis for this description.

Confirming the Applicant's control over the IP address 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 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. 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 Random Value contained in the
content of a file where 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 4.2.1 of these Guidelines or Section 11.14.3
of the EV Guidelines).

3) Since domain validation Method 9 has been deemed insecure, we should not
introduce that for IP address, so I would remove method 4 from your ballot.

4) I'd also delete  Method 5 because Domain Validation method 10 isn't
secure as written.

Doug

From: Public <public-bounces at cabforum.org
<mailto:public-bounces at cabforum.org> > On Behalf Of Tim Hollebeek via Public
Sent: Friday, August 17, 2018 9:04 AM
To: CA/B Forum Server Certificate WG Public Discussion List
<servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> >
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org
<mailto:public at cabforum.org> >
Subject: [cabfpub] Ballot SCx: "Remove Any Other Method" for IPs

This is what was previously posted as Ballot 222.  It already had the IP
validation methods moved to subsections, so it should work well with Wayne's
validation method disclosure ballot.

I suppose I'm looking for endorsers again, since this is technically a new
ballot.

-Tim

The following motion has been proposed by Tim Hollebeek of DigiCert and
endorsed by ??? 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 its 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 SCx 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180817/a123f45c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5736 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180817/a123f45c/attachment-0001.p7s>