[Servercert-wg] Ballot SC 13 version 3

Tue Nov 27 09:24:16 MST 2018

I agree its important to make sure everyone understands what this ballot does and how it should be implemented.

I agree about 1.

2.b. was also my intent and what I believe version 3 explicitly says.  I would expect most CAs to re-use their lookup implementation, to reduce the risk of new bugs.

For 3, I also agree.  CAs need to pay careful attention to what ADN they are using to authorize a particular FQDN, as this will effect which relevant Record Set will be found (as you correctly note).  Customers and people monitoring the issuance of certificates will need to be aware of this, as CAs currently do not disclose what ADN was used to validate a certificate.  That’s yet another thing related to validation that could use more transparency.  I really do wish there was more support for my Certificate Metadata Transparency idea, as there really is lots of interesting private data that CAs have about validation and issuance that could very reasonably be required to be made public.

It is very important for CAs to be careful to understand that validation through the CAA CONTACT methods, and CAA pre-issuance checking are two completely separate things that just happen to share a format and search algorithm and you need to do both, at distinct times in the issuance process.  This means that in these cases, there will be two CAA lookups, not one (for the single SAN case), and they will potentially retrieve different record sets depending on  the choice of ADN.  It’s not possible to combine them because you have to wait for the response to the email after the first one.

For 4, the ADN is what the CA says it is.  That’s pretty clear from the definition (“The CA may prune zero or more labels…”).  The location at which the relevant CAA record set is found by the search algorithm does not change the ADN.

My personal opinion is that version 3 of the ballot already says all of this, if read correctly.  But I appreciate the effort to make sure that we all agree on the proper interpretation of all of this, as it can be somewhat subtle.  Would appreciate hearing from anyone else if they disagree with any of these interpretations.

-Tim

From: Ryan Sleevi <sleevi at google.com> 
Sent: Monday, November 26, 2018 6:30 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>; servercert-wg at cabforum.org
Cc: Doug Beattie <doug.beattie at globalsign.com>
Subject: Re: [Servercert-wg] Ballot SC 13 version 3

Sorry for more suggestions, but I am wanting to make sure this ballot matches folks understanding and intent, and Doug's question I think rightfully highlights some confusion (it took me multiple reads and discussions with people to make sure I was coming up with consistent interpretations as others) - some of it I may have induced!

I've tried to distill it into concrete questions and thoughts about what the answers should be / rationale, but I'd be curious to know different answers or perspectives.

1) While this method is stated as intending to replace WHOIS, it does present something more permissive than our current WHOIS validation methods (in practice). While WHOIS lookup is similar in processing model as DNS, that is, start from the root server, work down the hierarchy each label, following references to the next server to query, it's fairly rare (citation needed) for servers to delegate WHOIS for subdomains (except in registrable domains), and more or less the wild-west once outside of the gTLD-and-registrar space. Is this OK?

I think this is OK, because this model bears more similarity to our DNS-based validation of control (such as TXT or CNAME) or the website validation of control (which relies on A/AAAA, even though we've not explicitly specified it as such, which is a problem with .6). That is, we've decided that hierarchal delegation past the registrar is OK, and so having TXT or CAA methods that obtain email addresses past the point of hierarchal delegation should equally be OK.

2) If we say it's OK, what should the search algorithm for CAA be? Options include:

  2.a) Use only the CAA record at the ADN; do not use the 6844 algorithm. CAA is only being used as a semi-structured record type, not as CAA-as-defined-by-6844

  2.b) Use the CAA search algorithm defined in 6844 (as amended) to obtain the Resource Record Set.

In these, I lean towards 2.b over 2.a, so that we do not create an overly complex series of special rules for CAs in processing CAA (whether they're processing the 'issue' and 'issuewild' tags, and any subsequent tags, vs this tag). I think it's conceptually and structurally simple to say "Whenever you're looking up a CAA record, you use the CAA algorithm" - that seems to reduce risk for implementations.

3) If we adopt 2.b, what is the processing algorithm and the ADN if you have a domain "a.b.example.com <http://a.b.example.com> ", which has CAA records on both "a.b.example.com <http://a.b.example.com> " and "b.example.com <http://b.example.com> "?

By adopting 2.b, we're saying the CAA Record Set for an ADN(a.b.example.com <http://a.b.example.com> ) is only that on "a.b.example.com <http://a.b.example.com> ", and that only that specific email is authorized - that is, the email address for "b.example.com <http://b.example.com> " MUST be ignored and not considered.

However, we also know that the CAA Record Set for ADN(b.example.com <http://b.example.com> ) will be the e-mail address in b.example.com <http://b.example.com> . Thus, it seems you SHOULD be able to authorize "a.b.example.com <http://a.b.example.com> " using the email address at a.b.example.com <http://a.b.example.com>  with the ADN of a.b.example.com <http://a.b.example.com> , or you can authorize a.b.example.com <http://a.b.example.com>  using the email address at b.example.com <http://b.example.com>  and an ADN of b.example.com <http://b.example.com> .

Further, because you can validate multiple FQDNs, but not ADNs, that share an e-mail, you MUST NOT send an email to *both* a.b.example.com <http://a.b.example.com>  and b.example.com <http://b.example.com> 's email addresses - those are separate validations (for the same FQDN), and thus need to have different secrets/values. I'm not sure if this makes sense, but I think that's the maximally restrictive reading of the current language.

All of this with one further caveat - if there is an "issue" or "issuewild" record for the FQDN, then I still have to respect that, independent of the contact method for the ADN. That is, if "a.b.example.com <http://a.b.example.com> " contains no contact e-mail, but an "issue" field, then even though the contactemail at "b.example.com <http://b.example.com> " approved it, I can't issue if they're not compatible.

4) If we adopt 2.b, what is the ADN if I attempt to validate using CAA, using the input domain of "a.b.example.com <http://a.b.example.com> ", and there's no CAA record on a.b.example.com <http://a.b.example.com> , but there is on b.example.com <http://b.example.com> ?

If I use the ADN of a.b.example.com <http://a.b.example.com> , and feed it to the specified algorithm, I'll get the CAA Record Set from b.example.com <http://b.example.com> . Does that mean the ADN was b.example.com <http://b.example.com> , because that's where the record set came from, or does it mean that the ADN was a.b.example.com <http://a.b.example.com> , because that's what I fed into the CAA algorithm?

I'm less clear here, but it seems a lurking source of bugs for CAs, so I'd think we want clarity.

5) Doug's response makes me think that some clarity/guidance is also appropriate for TXT record lookup, particularly around the situation where both "a.b.example.com <http://a.b.example.com> " and "b.example.com <http://b.example.com> " contain TXT records. Is it permitted to send e-mails to the union of the set to approve issuance?

I'm not sure it's a good idea, with the main argument against it being OK is whether or not "b.example.com <http://b.example.com> ", by approving "a.b.example.com <http://a.b.example.com> ", is being seen as approving all subsequent issuances for "b.example.com <http://b.example.com> " and subdomains, without that being clear. I'm not sure if this is more of a structural issue with ADNs and the lack of clarity as to whether an authorization is for a single certificate or reusable in perpetuity, and how a subscriber knows whether they are approving an FQDN or an ADN.

I'm not sure the best way to resolve these issues, either. I can appreciate discussion on list to flesh out the 'intent' of this ballot and its application, but in thinking how to spec any of the possible answers, this gets trickier. I suspect we'll want some degree of guidance about inputs and outputs (much like was done independently, and sadly, after multiple misissuances, for CAA), so that we can arrive at a test suite for compatible implementations solely by reading the spec. In other SDOs, this is generally done via a "test suite" that accompanies the spec and thus serves as interpretative guidance for any ambiguity, and any untested ambiguity can then be added as a new test to see real world results.

On Wed, Nov 21, 2018 at 1:51 PM Tim Hollebeek via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> > wrote:

As before, there is both a full redline, and a diff since the last version.

Ballot SC13: CAA Contact Property and Associated E-mail 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.6.0:

Add Section 3.2.2.4.13: Email to DNS CAA Contact

Confirming the Applicant's control over the FQDN by sending a Random Value via email and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to an email address identified as a CAA contactemail property record as defined in Appendix B.  The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 6844 Section 4, as amended by Errata 5065 (Appendix A).

Each email MAY confirm control of multiple FQDNs, provided that the DNS contactemail email address is the same for each Authorized Domain Name being validated.

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: Email to DNS TXT Contact

Confirming the Applicant's control over the FQDN by sending a Random Value via email and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to an email address identified as a DNS TXT record email contact for

an Authorization Domain Name.  See Appendix B for the format of

the DNS TXT record email contact.

Each email MAY confirm control of multiple FQDNs, provided that the DNS contactemail email address is the same for each Authorized Domain Name being validated.

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 Appendix B: DNS Contact Properties

These methods allow domain owners to publish contact information in DNS for the purpose of validating domain control.

B.1. CAA Methods

B.1.1. CAA contactemail Property

SYNTAX: contactemail <rfc6532emailaddress> 

The CAA contactemail property takes an email address as its parameter.  The entire parameter value MUST be a valid email address as defined in RFC 6532 section 3.2, with no additional padding or structure, or it cannot be used.

The following is an example where the holder of the domain specified the contact property using an email address.

$ORIGIN example.com <http://example.com> 

.              CAA 0 contactemail "domainowner at example.com <mailto:domainowner at example.com> "

The contactemail property MAY be critical, if the domain owner does not want CAs who do not understand it to issue certificates for the domain.

B.2. DNS TXT Methods

B.2.1. DNS TXT Email Contact

The DNS TXT record MUST be placed on the "_validation-contactemail" subdomain of the domain being validated.  The entire RDATA value of this TXT record MUST be a valid email address as defined in RFC 6532 section 3.2, with no additional padding or structure, or it cannot be used.

--- MOTION ENDS ---

*** WARNING ***: USE AT YOUR OWN RISK.  THE REDLINE BELOW IS NOT THE OFFICIAL VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(a)):

A comparison of the changes can be found at: https://github.com/cabforum/documents/compare/Ballot-SC4---CAA-CONTACT-email?diff=unified <https://github.com/cabforum/documents/compare/Ballot-SC4---CAA-CONTACT-email?diff=unified&expand=1> &expand=1

The changes between version 3 and version 2 are here:

https://github.com/cabforum/documents/commit/e8e24ae14bf68f22a9bb13edc7201896fa948641?short_path=7f6d14a#diff-7f6d14a20e7f3beb696b45e1bf8196f2

The procedure for approval of this ballot is as follows:

Discussion (7+ days)

Start Time: 2018-11-21 2:00 PM Eastern

End Time: Not before 2018-11-28 2:00 PM Eastern

Vote for approval (7 days)

Start Time: TBD

End Time: TBD

_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org <mailto: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/20181127/95f6d9e9/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/servercert-wg/attachments/20181127/95f6d9e9/attachment-0001.p7s>