[Servercert-wg] Voting Begins: Ballot SC7: Update IP Address Validation Methods CAB Forum x
Erhan TURAN (TÜBİTAK-BİLGEM-KAMUSM))
erhan.turan at kamusm.gov.tr
Mon Feb 4 00:11:16 MST 2019
Kamu SM votes "YES" on ballot SC7.
Thank you,
--
--
*Erhan TURAN*
Lead e-Signature Tech. Expert
BİLGEM/KamuSM
TÜBİTAK BİLGEM
06200 Yenimahalle, ANKARA
T +90 262 648 1818 - 8542
F +90 262 648 1800
www.bilgem.tubitak.gov.tr
erhan.turan at tubitak.gov.tr
................................................................
<http://bilgem.tubitak.gov.tr>
Sorumluluk Reddi <http://www.tubitak.gov.tr/sorumlulukreddi>
3.2.2019 17:52 tarihinde xiulei--- via Servercert-wg yazdı:
> GDCA votes YES on ballot SC7.
>
> Thanks.
>
> ------------------------------------------------------------------------
> xiulei at gdca.com.cn
>
> *From:* Wayne Thayer via Servercert-wg
> <mailto:servercert-wg at cabforum.org>
> *Date:* 2019-02-02 02:30
> *To:* CA/B Forum Server Certificate WG Public Discussion List
> <mailto:servercert-wg at cabforum.org>
> *Subject:* [Servercert-wg] Voting Begins: Ballot SC7: Update IP
> Address Validation Methods CAB Forum x
>
> 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
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
Sorumluluk Reddi
Bu e-posta mesaji ve onunla iletilen tum ekler gonderildigi kisi ya da kuruma ozel olup, gizli imtiyazli, ozel bilgiler icerebilecegi gibi gizlilik yukumlulugu de tasiyor olabilir. Bu mesajda ve ekindeki dosyalarda bulunan tum fikir ve gorusler sadece adres yazarina ait olup, TUBITAK / Kamu SM?nin resmi gorusunu yansitmaz. TUBITAK / Kamu SM bu e-posta icerigindeki bilgilerin kullanilmasi nedeniyle hic kimseye karsi sorumlu tutulamaz. Mesajin yetkili alicisi veya alicisina iletmekten sorumlu kisi degilseniz, mesaj icerigini ya da eklerini kullanmayiniz, kopyalamayiniz, yaymayiniz, baska kisilere yonlendirmeyiniz ve mesaji gonderen kisiyi derhal e-posta yoluyla haberdar ederek bu mesaji ve eklerini herhangi bir kopyasini muhafaza etmeksizin siliniz. Kurumumuz size, mesajin ve bilgilerinin degisiklige ugramamasi, butunlugunun ve gizliligin korunmasi konusunda garanti vermemekte olup, e-posta icerigine yetkisiz olarak yapilan mudahale, virus icermesi ve/veya bilgisayar sisteminize verebilecegi herhangi bir zarardan da sorumlu degildir.
******************************************
Disclaimer
This e-mail message, including any attachments, is intended only for the use of the individual or entity to whom it is addressed and may contain confidential, privileged, private information as well as the exemption from disclosure. The information and views set out in this email are those of the author and do not necessarily reflect the official position of TUBITAK / Kamu SM. TUBITAK / Kamu SM shall have no liability to any person with regard to the use of the information contained in this message. If you are not the intended addressee(s) or responsible person to inform the addressee(s), you are hereby notified that; any use, dissemination, distribution, or copying of this message and attached files is strictly prohibited. Please notify the sender immediately by e-mail and delete this message and any attachments without retaining a copy. TUBITAK / Kamu SM do not warrant for the accuracy, completeness of the contents of this email and/or the preservation of confidentiality, and shall not be liable for the unauthorized changes made to this message, viruses and/or any damages caused in any way to your computer system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190204/20f77486/attachment-0001.html>
More information about the Servercert-wg
mailing list