[cabf_validation] Draft ballot from London on CAA Contact

Mon Jul 9 11:13:52 MST 2018

Insisting on IETF involvement is a change from your position in London.  I object to using IETF as a roadblock on this important issue.  As we all agreed in London, this can be done without having to get IETF involved.  Given that the scope of CAA is precisely public server auth web certificates (clarified directly by the author when there was some disagreement), CABForum is a far more relevant body.

In case it’s not clear, the “e.g.” was meant to be normative.  I welcome any suggested improvements that make it more clear that it MUST be in exactly that format.

It just says it will be submitted to IETF.  It’s up to IETF whether they want to put it in RFC 6844 or not.  I don’t really care if that text is in the ballot or not.

The ABNF is exactly the same as the existing IODEF tag.  If you have problems with that, you should take it your issues to LAMPS and get the IODEF tag ABNF fixed first.  I’d be more than happy to update this in parallel.

-Tim

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Friday, July 6, 2018 7:38 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Draft ballot from London on CAA Contact

As noted during the F2F, adding as TXT records is seen as problematic in a number of areas, least of all within the IETF.

Some suggestions that may not have been fully captured in the minutes of that discussion included normatively specifying the DNS label that would provide this information, rather than just saying "a TXT record". Further, this would make more sense to describe in the context of the IETF, much like has been done for CAA, if going the TXT route. We'd be OPPOSED to simplify specifying it in the Forum without having made an effort to go through that route first. See https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-fix for extremely relevant and overlapping efforts in that space.

If going the CAA route, more work is needed on the ABNF. Also, we'd OBJECT to the suggestion of including in a future update of 6844 - that's putting the cart before the horse. In particular, and as noted during the F2F, the semantic interpretation of the 'contact' field is specific to the Web PKI use case, and its context of the Baseline Requirements. The point of having a protocol-defined registry is so that you don't have to shove all the registrations into a single specification, nor would you necessarily want to.

On Fri, Jul 6, 2018 at 5:05 PM Tim Hollebeek via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

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 <mailto: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://example.com> 

.              CAA 0 issue “ca.example.net <http://ca.example.net> ”

.              CAA 0 contact “mailto:domainowner at example.com <mailto:domainowner at example.com> ”

.              CAA 0 contact “tel:+1 310 555 1212 <tel:+1%20310%20555%201212> ”

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

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

_______________________________________________
Validation mailing list
Validation at cabforum.org <mailto:Validation at cabforum.org> 
https://cabforum.org/mailman/listinfo/validation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180709/c93d4bdf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180709/c93d4bdf/attachment-0001.p7s>