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

[Tomasz Nowak]

Opera Software AS votes YES on ballot SC2.

Thanks,
Tomasz Nowak

On Thu, Jul 19, 2018 at 5:02 PM, Tim Hollebeek via Servercert-wg <
servercert-wg at cabforum.org> wrote:

>
>
> 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
>
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180720/6c1920ad/attachment.html>