[cabf_validation] Draft ballot from London on CAA Contact

[Ryan Sleevi]

The minutes that were circulated -
https://cabforum.org/pipermail/validation/2018-June/000952.html - capture
the discussion around CAA, rather than TXT.

To be clear, you've made two proposals:
- Use TXT
- Use CAA

As proposed, "use TXT" is bad for a number of dimensions, and needs IETF
involvement. This is not a roadblock - this is making sure that we
appropriately engage the Standards community, for things that clearly have
global impact. Failure to do that is not an option, as there are a whole
host of issues with the draft, as proposed, and as captured in the document
I sent. As proposed, it's insecure, it creates real global compatibility
issues, and misunderstands or misuses key technologies. That's something we
object to, because that is unacceptable of any SDO, and the IETF is the far
more relevant body to make sure this gets done correctly.

We shared this position during the validation meeting, and while it's not
captured by the minutes, we stand by it. That is, on multiple dimensions,
the use of TXT records is bad, and will require substantially more work.
I'm happy to re-review the recording from the meeting to write those up, if
it would help jog the memory of what was previously discussed.

For "Use CAA", more work is needed than what has been done, but as captured
in the minutes, we're supportive of the direction. That said, there are
steps to do it correctly, and it's important to do it correctly. This means
more work for the ballot proposer, but that's because doing something right
requires more time than doing something poorly and hastily. As was
discussed, an Independent Submission can be made on behalf of the
CA/Browser Forum that defines the contact CAA tag in an unambiguous way.
This technical specification can be hammered out, hopefully far easier than
the policy issues, to define a specification for both the syntax and
processing.

There's a path forward, but trying to rush it through won't get us there.
We're happy to work with you to get it right, but we're nowhere near close
enough for a ballot on it - at least, not without introducing substantial
security and compatibility concerns.

On Mon, Jul 9, 2018 at 2:13 PM Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> 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> 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 <+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
> https://cabforum.org/mailman/listinfo/validation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180709/d8c4db7b/attachment-0001.html>