[cabf_validation] Endorsers for removing any other IP method

Ryan Sleevi sleevi at google.com
Mon Jul 9 11:38:11 MST 2018


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> 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> 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
>> https://cabforum.org/mailman/listinfo/validation
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180709/fad26ca2/attachment-0001.html>


More information about the Validation mailing list