[Servercert-wg] Ballot SCx: "Remove Any Other Method" for IPs
Wayne Thayer
wthayer at mozilla.com
Fri Aug 17 10:16:10 MST 2018
Thanks for pulling this together Tim. I would also be happy to endorse once
we get it cleaned up. I noticed a few wording issues - can we put this on
GitHub and collaborate there? I'm happy to do that if you'd like.
Wayne
On Fri, Aug 17, 2018 at 9:56 AM Tim Hollebeek via Servercert-wg <
servercert-wg at cabforum.org> wrote:
> Yup, good points. Thanks for the help.
>
>
>
> -Tim
>
>
>
> *From:* Doug Beattie <doug.beattie at globalsign.com>
> *Sent:* Friday, August 17, 2018 12:26 PM
> *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
>
>
>
> Sorry, I meant to say 3.2.2.5.2 (not .1) is similar to 2.3.3.4.1. I’ll
> make some edits and send it over to you for your consideration because I
> don’t think we want to “look at company names to verify ownership” for IP
> address validation, it should be a challenge/response.
>
>
>
> We should also discuss the effective date for this in 2 ways and include
> in the ballot:
>
> 1. When all new validations need to be performed using these methods
> 2. When IP address validations done using anything else can’t be used
> to issue certificates.
>
>
>
> Doug
>
>
>
> *From:* Tim Hollebeek <tim.hollebeek at digicert.com>
> *Sent:* Friday, August 17, 2018 10:22 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
>
>
>
> 3.2.2.5.1 is not based on 3.2.2.4.1, it’s actually based on 3.2.2.4.6.
>
>
>
> -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> *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>
> *Cc:* CA/Browser Forum Public Discussion List <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.
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180817/f1ecb88a/attachment-0001.html>
More information about the Servercert-wg
mailing list