[cabfpub] Voting Begins: Ballot SC2 - version 2: Validating certificates via CAA CONTACT

Adriano Santoni adriano.santoni at staff.aruba.it
Thu Jul 26 14:12:26 UTC 2018


Actalis "abstains" on this ballot.


Il 19/07/2018 17:02, Tim Hollebeek via Public ha scritto:
>
> Administrivia:
>
>  1. This ballot is being cross-posted to the CABF public mailing in
>     line with the consensus from last Thursday’s call that it is
>     important everyone is aware of the ballot, and that not everyone
>     is on the SCWG list yet.
>  2. I promised an IETF independent stream draft for the same proposal,
>     so it can get feedback from those at IETF.  I still intend to do
>     so, but I am working with a colleague on setting up a github
>     account for DigiCert IETF efforts to make it easier for others to
>     collaborate with us on IETF submissions.  I anticipate we will
>     have that set up and the draft submitted some time next week.  The
>     IETF draft will allow IETF to review the method and make suggested
>     improvements.  It should not block adoption of the current
>     proposal by CABF. DigiCert intends to submit a ballot to adopt
>     IETF’s improvements once the IETF process is complete.
>
> Ballot SC2: CAA Contact Property and Associated Validation Methods
>
> Purpose of Ballot: Increasingly, contact information is not available 
> in WHOIS due to concerns about potential GDPR violations.  This ballot 
> specifies a method by which domain holders can publish their contact 
> information via DNS, and how CAs can use that information for 
> validating domain control.
>
> The following motion has been proposed by Tim Hollebeek of DigiCert 
> and endorsed by Bruce Morton of Entrust and Doug Beattie of GlobalSign.
>
> --- MOTION BEGINS ---
>
> This ballot modifies the “Baseline Requirements for the Issuance and 
> Management of Publicly-Trusted Certificates” as follows, based on 
> Version 1.5.7:
>
> Add Section 3.2.2.4.13: Domain Owner Email published in DNS
>
> Confirm the Applicant's control over the FQDN by (i) sending an email 
> to a DNS domain name holder, (ii) including a Random Value in the 
> email, and (iii) receiving a confirming response utilizing the Random 
> Value. The CA MUST send the email to an email address found in the CAA 
> Contact property record as defined in Appendix B.
>
> Each email MAY confirm control of multiple FQDNs, provided the email 
> address used is a DNS contact email address for each FQDN being 
> confirmed.
>
> The Random Value SHALL be unique in each email. The email MAY be 
> re-sent in its entirety, including the re-use of the Random Value, 
> provided that its entire contents and recipient SHALL 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.
>
> Note: Once the FQDN has been validated using this method, the CA MAY 
> also issue Certificates for other FQDNs that end with all the labels 
> of the validated FQDN. This method is suitable for validating Wildcard 
> Domain Names.
>
> Add Section 3.2.2.4.14: Domain Owner Phone published in DNS
>
> Confirm the Applicant's control over the FQDN by calling the DNS 
> domain name holder phone number and obtaining a response confirming 
> the Applicant's request for validation of the FQDN. The CA MUST place 
> the call to a phone number identified in the CAA Contact property 
> record as defined in Appendix B.
>
> Each phone call SHALL be made to a single number and MAY confirm 
> control of multiple FQDNs, provided that the phone number is 
> identified by the DNS contact as a valid contact method for every Base 
> Domain Name being verified using the phone call.
>
> Note: Once the FQDN has been validated using this method, the CA MAY 
> also issue Certificates for other FQDNs that end with all the labels 
> of the validated FQDN. This method is suitable for validating Wildcard 
> Domain Names.
>
> Add Section 3.2.2.4.15: Domain Owner Email published in TXT record
>
> Confirm the Applicant's control over the FQDN by (i) sending an email 
> to a DNS domain name holder, (ii) including a Random Value in the 
> email, and (iii) receiving a confirming response utilizing the Random 
> Value. The CA MUST send the email to an email address found in the DNS 
> TXT record as defined in Appendix B.
>
> Each email MAY confirm control of multiple FQDNs, provided the email 
> address used is a DNS contact email address for each FQDN being 
> confirmed.
>
> The Random Value SHALL be unique in each email. The email MAY be 
> re-sent in its entirety, including the re-use of the Random Value, 
> provided that its entire contents and recipient SHALL 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.
>
> Note: Once the FQDN has been validated using this method, the CA MAY 
> also issue Certificates for other FQDNs that end with all the labels 
> of the validated FQDN. This method is suitable for validating Wildcard 
> Domain Names.
>
> ##### 3.2.2.4.16 Domain Owner Phone published in TXT record
>
> Confirm the Applicant's control over the FQDN by calling the DNS 
> domain name holder phone number and obtaining a response confirming 
> the Applicant's request for validation of the FQDN. The CA MUST place 
> the call to a phone number identified in the DNS TXT record defined in 
> Appendix B.
>
> Each phone call SHALL be made to a single number and MAY confirm 
> control of multiple FQDNs, provided that the phone number is 
> identified by the DNS contact as a valid contact method for every Base 
> Domain Name being verified using the phone call.
>
> Note: Once the FQDN has been validated using this method, the CA MAY 
> also issue Certificates for other FQDNs that end with all the labels 
> of the validated FQDN. This method is suitable for validating Wildcard 
> Domain Names.
>
> Add Appendix B: CAA Contact Tag
>
> The syntax for the contact property is similar to the iodef property.  
> It allows domain owners to publish contact information in DNS in 
> addition to WHOIS for the purpose of validating domain control.
>
> CAA contact Property
>
> contact <URL> :  The contact property entry specifies the authorized 
> means of contacting the holder of the domain or another party who is 
> authorized to approve issuance of certificates for the domain.
>
> The contact property specifies a means of contacting the domain 
> holder, or another party that is authorized to approve issuance of 
> certificates for the domain in question.
>
> The contact property takes a URL as its parameter.  The following URL 
> scheme types SHOULD be implemented:
>
> mailto: An SMTP email address where the domain holder or other 
> authorized party can be contacted.
>
> tel: A telephone number where the domain holder or other authorized 
> party can be contacted.
>
> Schemes other than "mailto:" or "tel:" MUST NOT be used.  Telephone 
> numbers MUST include the country code and be global phone numbers as 
> defined by RFC 3966.
>
> The following is an example where the holder of the domain specified 
> the contact property using both an email address and a phone number.
>
> $ORIGIN example.com
>
> .              CAA 0 issue “ca.example.net”
>
> .              CAA 0 contact “mailto:domainowner at example.com>
> .              CAA 0 contact “tel:+1-310-555-1212”
>
> ## Support for Legacy Systems
>
> Some systems still do not have sufficient support for CAA records.  To 
> allow users of those systems to specify contact information, a legacy 
> format using text records is allowed.  The CAA contact property SHOULD 
> be used instead of TXT records, where feasible.
>
> The DNS TXT record MUST be placed on the "_caa_contact" subdomain of 
> the domain being validated.  The DNS record MUST be named 
> "domain-authorization-email" or "domain-authorization-phone".  The 
> value of "domain-authorization-email" MUST contain a valid email 
> address, or it cannot be used.  The value of 
> "domain-authorization-phone" must be a global phone number, including 
> country code, as defined in RFC 3966 or it cannot be used.
>
> --- MOTION ENDS ---
>
> A comparison of the changes can be found at: 
> https://github.com/cabforum/documents/compare/SC2-CAA-Contact?expand=1
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
>
> Start Time: 2018-07-11 10:30am EST
>
> End Time: 2018-07-19 11:00am EST
>
> Vote for approval (7 days)
>
> Start Time: 2018-07-19 11:00am EST
>
> End Time: 2018-07-26 11:00am EST
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180726/54aa121c/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4025 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180726/54aa121c/attachment-0003.p7s>


More information about the Public mailing list