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]> wrote: > Yup, good points. Thanks for the help. > > > > -Tim > > > > *From:* Doug Beattie <[email protected]> > *Sent:* Friday, August 17, 2018 12:26 PM > *To:* Tim Hollebeek <[email protected]>; CA/Browser Forum Public > Discussion List <[email protected]>; CA/B Forum Server Certificate WG > Public Discussion List <[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]> > *Sent:* Friday, August 17, 2018 10:22 AM > *To:* Doug Beattie <[email protected]>; CA/Browser Forum Public > Discussion List <[email protected]>; CA/B Forum Server Certificate WG > Public Discussion List <[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]> > *Sent:* Friday, August 17, 2018 9:41 AM > *To:* Tim Hollebeek <[email protected]>; CA/Browser Forum Public > Discussion List <[email protected]>; CA/B Forum Server Certificate WG > Public Discussion List <[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]> *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]> > *Cc:* CA/Browser Forum Public Discussion List <[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] > http://cabforum.org/mailman/listinfo/servercert-wg >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
