It’s there now (https://github.com/cabforum/documents/blob/Ballot-SC7---IP-any-other-method/docs/BR.md). Feel free to make any comments or pull requests.
-Tim From: Wayne Thayer <[email protected]> Sent: Friday, August 17, 2018 1:16 PM To: Tim Hollebeek <[email protected]>; CA/B Forum Server Certificate WG Public Discussion List <[email protected]> Cc: Doug Beattie <[email protected]>; CA/Browser Forum Public Discussion List <[email protected]> Subject: Re: [Servercert-wg] Ballot SCx: "Remove Any Other Method" for IPs 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 <[email protected] <mailto:[email protected]> > wrote: Yup, good points. Thanks for the help. -Tim From: Doug Beattie <[email protected] <mailto:[email protected]> > Sent: Friday, August 17, 2018 12:26 PM To: Tim Hollebeek <[email protected] <mailto:[email protected]> >; CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]> >; CA/B Forum Server Certificate WG Public Discussion List <[email protected] <mailto:[email protected]> > 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 <[email protected] <mailto:[email protected]> > Sent: Friday, August 17, 2018 10:22 AM To: Doug Beattie <[email protected] <mailto:[email protected]> >; CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]> >; CA/B Forum Server Certificate WG Public Discussion List <[email protected] <mailto:[email protected]> > 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 <[email protected] <mailto:[email protected]> > Sent: Friday, August 17, 2018 9:41 AM To: Tim Hollebeek <[email protected] <mailto:[email protected]> >; CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]> >; CA/B Forum Server Certificate WG Public Discussion List <[email protected] <mailto:[email protected]> > 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 <[email protected] <mailto:[email protected]> > 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 <[email protected] <mailto:[email protected]> > Cc: CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]> > 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 [email protected] <mailto:[email protected]> http://cabforum.org/mailman/listinfo/servercert-wg
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
