[Servercert-wg] Voting Begins: Ballot SC7: Update IP Address Validation Methods CAB Forum x

Mon Feb 4 11:22:14 MST 2019

Certum votes YES on Ballot SC7.

-Wojciech Trapczyński

On 01.02.2019 19:30, Wayne Thayer via Servercert-wg wrote:
> Purpose of Ballot:
> 
> 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.
> 
> 
> The following motion has been proposed by Wayne Thayer of Mozilla and 
> endorsed by Doug Beattie of GlobalSign and Tim Hollebeek of DigiCert.
> 
> 
> -- MOTION BEGINS --
> 
> This ballot modifies the “Baseline Requirements for the Issuance and 
> Management of Publicly-Trusted Certificates” as follows, based on 
> Version 1.6.2:
> 
> Add the following to the table in section 1.2.2:
> 
> Compliance: 2019-08-01; Section 3.2.2.5; Summary Description: CAs MUST 
> follow revised validation requirements in section 3.2.2.5 and MUST keep 
> a record of IP Address validation methods used.
> 
> 
> Add the following definitions to section 1.6.1:
> 
> IP Address:A 32-bit or 128-bit label assigned to a device that uses the 
> Internet Protocol for communication.
> 
> IP Address Contact:The person(s) or entity(ies) registered with an IP 
> Address Registration Authority as having the right to control how one or 
> more IP Addresses are used.
> 
> IP Address Registration Authority:The  Internet Assigned Numbers 
> Authority (IANA) or a Regional Internet Registry (RIPE, APNIC, ARIN, 
> AfriNIC, LACNIC).
> 
> 
> Replace Baseline Requirements section 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 a Certificate.
> 
> The CA SHALL confirm that prior to issuance, the CA has validated each 
> IP Address listed in the Certificate using at least one of the methods 
> specified in this section.
> 
> Completed validations of Applicant authority may be valid for the 
> issuance of multiple Certificates over time. In all cases, the 
> validation 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.
> 
> After July 31, 2019, CAs SHALL maintain a record of which IP validation 
> method, including the relevant BR version number, was used to validate 
> every IP Address.
> 
> Note: IP Addresses verified in accordance with this section 3.2.5 may be 
> listed in Subscriber Certificates as defined in section 7.1.4.2 or in 
> Subordinate CA Certificates via iPAddress in permittedSubtrees within 
> the Name Constraints extension. CAs are not required to verify IP 
> Addresses listed in Subordinate CA Certificates via iPAddress in 
> excludedSubtrees in the Name Constraints extension prior to inclusion in 
> the Subordinate CA Certificate.
> 
> 3.2.2.5.1. Agreed-Upon Change to Website
> 
> Confirming 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 under the 
> "/.well-known/pki-validation" directory, or another path registered with 
> IANA for the purpose of validating control of 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 4.2.1 of this document).
> 
> 3.2.2.5.2. Email, Fax, SMS, or Postal Mail to IP Address Contact
> 
> Confirming the Applicant's control over the IP Address  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 an IP Address Contact.
> 
> Each email, fax, SMS, or postal mail MAY confirm control of multiple IP 
> Addresses.
> 
> The CA 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 IP Address Registration Authority as representing the 
> IP Address Contact for every IP Address 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 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.
> 
> 3.2.2.5.3. Reverse Address Lookup
> 
> Confirming 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 FQDN using a 
> method permitted under BR Section 3.2.2.4.
> 
> 3.2.2.5.4. Any Other Method
> 
> Using any other method of confirmation, including variations of the 
> methods defined in BR Section 3.2.2.5, provided that the CA maintains 
> documented evidence that the method of confirmation establishes that the 
> Applicant has control over the IP Address to at least the same level of 
> assurance as the methods previously described in version 1.6.2 of these 
> Requirements.
> 
> CAs SHALL NOT perform validations using this method after July 31, 
> 2019.  Completed validations using this method SHALL NOT be re-used for 
> certificate issuance after July 31, 2019. Any certificate issued prior 
> to August 1, 2019 containing an IP Address that was validated using any 
> method that was permitted under the prior version of this section 
> 3.2.2.5 MAY continue to be used without revalidation until such 
> certificate naturally expires.
> 
> 3.2.2.5.5. Phone Contact with IP Address Contact
> 
> Confirming the Applicant's control over the IP Address by calling the IP 
> Address Contact’s phone number and obtaining a response confirming the 
> Applicant's request for validation of the IP Address. The CA MUST place 
> the call to a phone number identified by the IP Address Registration 
> Authority as the IP Address Contact. Each phone call SHALL be made to a 
> single number.
> 
> In the event that someone other than an IP Address Contact is reached, 
> the CA MAY request to be transferred to the IP Address Contact.
> 
> In the event of reaching voicemail, the CA may leave the Random Value 
> and the IP Address(es) being validated.  The Random Value MUST be 
> returned to the CA to approve the request.
> 
> 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.
> 
> 
> *3.2.2.5.6 ACME “http-01” method for IP Addresses*
> 
> 
> Confirming the Applicant's control over the IP Address by performing the 
> procedure documented for an “http-01” challenge in draft 04 of “ACME IP 
> Identifier Validation Extension,” available at 
> https://tools.ietf.org/html/draft-ietf-acme-ip-04#section-4.
> 
> 
> *3.2.2.5.7 ACME “tls-alpn-01” method for IP Addresses*
> 
> 
> Confirming the Applicant's control over the IP Address by performing the 
> procedure documented for a “tls-alpn-01” challenge in draft 04 of “ACME 
> IP Identifier Validation Extension,” available at 
> https://tools.ietf.org/html/draft-ietf-acme-ip-04#section-4.
> 
> -- MOTION ENDS --
> 
> 
> *** WARNING ***: USE AT YOUR OWN RISK.  THE REDLINE BELOW IS NOT THE 
> OFFICIAL VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(a)):
> 
> A comparison of the changes can be found 
> at:https://github.com/wthayer/documents/compare/wthayer:master...Ballot-SC7 
> <https://github.com/dougbeattie/documents/compare/master...dougbeattie:SC14---Phone-validation-updates>
> 
> The procedure for approval of this ballot is as follows:
> 
> Discussion (7+ days)
> 
> Start Time: 2019-01-24 01:00 UTC
> 
> End Time: Not before 2019-01-31 01:00 UTC
> 
> Vote for approval (7 days)
> 
> Start Time: 2019-02-01 19:00 UTC
> 
> End Time: 2019-02-08 19:00 UTC
> 
> 
> This body part will be downloaded on demand.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3785 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190204/10fec7c7/attachment.p7s>