[cabf_validation] Draft ballot from London on CAA Contact

Tue Jul 10 12:36:17 MST 2018

Hi Tim,
Thanks for sending this proposal out. Hopefully once allowed, these methods will ease customer pain brought on by GDPR.

I have yet to give this proposal a comprehensive reading, but a few things jumped out at me that I wanted to point out:

  1.  In appendix B, it sounds like it’s possible to use URI schemes other than “tel” and “mailto”, as there’s no MUST NOT prohibiting implementations that support other schemes. Perhaps I’m being too strict with that reading, but I thought it would be good to explicitly list the allowed schemes and disallow all others.
  2.  The example for tel: isn’t a valid URI, as there’s unescaped spaces. The example should probably just use hyphens as visual separators as RFC 3966 (the tel: RFC), states in section 5.1.1 that “"tel" URIs MUST NOT use spaces in visual separators to avoid excessive escaping.”
  3.  There is no requirement that tel: URIs specify globally unique numbers (“global-numbers” in RFC 3966 parlance; see section 5.1.4 for details), which may provide for interesting attack vectors due to number collisions depending on the number context.
  4.  There is more than one RFC relating to the mailto: scheme, with differences mainly stemming from differences in handling internationalized email addresses (RFC 6068 allows for percent-encoded domain names, among other notable differences from RFC 2368). I think it would be good to explicitly specify the RFC in appendix B (likely RFC 6068) so that potential issues between differences in handling the two RFCs is mitigated.
  5.  Likewise, the DNS TXT mechanism doesn’t prescribe the encoding of the email address.

Thanks,

Corey Bonnell
Senior Software Engineer

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>

From: Validation <validation-bounces at cabforum.org> on behalf of Tim Hollebeek via Validation <validation at cabforum.org>
Reply-To: Tim Hollebeek <tim.hollebeek at digicert.com>, CA/Browser Forum Validation WG List <validation at cabforum.org>
Date: Friday, July 6, 2018 at 5:05 PM
To: CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: [cabf_validation] Draft ballot from London on CAA Contact

I’d like to get endorsers and start discussing this.  It will allow DNS-savvy customers to get around registrars/registries that redact contact information due to an overly-broad application of GDPR.

I’m leaving SC1 available for a ballot on elections, etc.

Draft text:

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 ??? and ???.

--- 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:
1.            DNS TXT record specified as "domain-authorization-contact" (e.g., domain-authorization-contact=domainowner at example.com), or
2.            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:

1.            DNS TXT record specified as "domain-authorization-contact" (e.g., domain-authorization-contact=+1 310 555 1212), or
2.            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 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.

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<http://scanmail.trustwave.com/?c=4062&d=iNm_272qd-xT4sAfFDtFwGEZSMvRD23z6BzA6ks4rg&s=5&u=http%3a%2f%2fexample%2ecom>
.              CAA 0 issue “ca.example.net”
.              CAA 0 contact “mailto:domainowner at example.com”
.              CAA 0 contact “tel:+1 310 555 1212”

The CONTACT tag will also be registered with IANA as a reserved CAA tag, and will be submitted for inclusion in a future version of RFC 6844.

--- MOTION ENDS ---

A comparison of the changes can be found at: https://github.com/cabforum/documents/commit/d71fea31b69d5541cb34b9c2cae567d6ade7e3a2#diff-7f6d14a20e7f3beb696b45e1bf8196f2<https://scanmail.trustwave.com/?c=4062&d=iNm_272qd-xT4sAfFDtFwGEZSMvRD23z6BmW7Rk_qw&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2fcommit%2fd71fea31b69d5541cb34b9c2cae567d6ade7e3a2%23diff-7f6d14a20e7f3beb696b45e1bf8196f2>

The procedure for approval of this ballot is as follows:

Discussion (7+ days)

Start Time: TBD

End Time: TBD

Vote for approval (7 days)

Start Time: TBD

End Time: TBD

-Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180710/ae00d373/attachment-0001.html>