[cabf_validation] Draft ballot from London on CAA Contact

[Ryan Sleevi]

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> 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), 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
>
> .              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
>
>
>
> 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
> https://cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180706/fb772d7c/attachment.html>