[Servercert-wg] Ballot SC4 - email and CAA CONTACT

Tue Aug 7 17:16:23 MST 2018

On Tue, Aug 7, 2018 at 7:29 PM Tim Hollebeek via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> No, I don’t think that scheme-based encodings and representations outside
> of a URI scheme is a reasonable interpretation of the text as written.  The
> draft text specifically states that the contents must be a valid email
> address.  That means it must be represented in the standard way, without
> alternative encodings or other silliness.
>

"in the standard way" is inherently ambiguous though. Corey's point - of
using a URI - at least resolves some of that ambiguity and allows for a
single parser, rather than, as proposed, requiring two distinct parsers. Is
there a downside to the URI approach proposed?

>
>
> I can put in the RFC 6532 reference to make that even more clear than it
> already is.  But I don’t want to have another Ballot 219 where we’re doing
> a lot of work to add text specifically to rule out unreasonable
> interpretations.  There’s an infinite amount of work down that road.
>
>
>
> -Tim
>
>
>
> *From:* Corey Bonnell <CBonnell at trustwave.com>
> *Sent:* Tuesday, August 7, 2018 3:32 PM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>;
> CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [Servercert-wg] Ballot SC4 - email and CAA CONTACT
>
>
>
> Tim,
>
> If Internationalized Email Address support is desired, then for
> completeness, “valid” should be more concretely defined. The reason why I
> think merely stating “valid” is insufficient is that there are multiple
> ways to encode an email address, and inconsistent handling of these values
> across CA implementations may create vulnerabilities where attackers can
> obtain certificates for domains that they don’t control.
>
>
>
> As an example, a “valid” email address could be interpreted as the
> scheme-specific part of a mailto: URL (eg, the foo at example.com in
> mailto:foo at example.com <foo at example.com>). The CAA “contact” property tag
> specifies a mailto: URL, so it reasonable to think that the TXT record
> does as well. URI-encoding of the scheme-specific part (see RFC 6068,
> section 2 https://tools.ietf.org/html/rfc6068#section-2) differs from an
> email address encoded as specified in RFC 6532, section 3.2 (
> https://tools.ietf.org/html/rfc6532#section-3.2). Given the differences
> between these encodings, it would be possible for an attacker to find a CA
> that uses a different encoding than the CA that the domain owner used and
> setup a mailbox such that they receive the DV email when requesting a
> certificate for the victim domain from the other CA.
>
>
>
> For this reason, I think that explicitly mandating “a RFC 6532-compliant
> email address” would be prudent. Or alternatively, change the TXT record to
> specify a mailto: URL so that it is consistent with the CAA syntax.
>
>
>
> Thanks,
>
> Corey
>
>
>
>
>
> *From: *Tim Hollebeek <tim.hollebeek at digicert.com>
> *Date: *Tuesday, August 7, 2018 at 10:59 AM
> *To: *Corey Bonnell <CBonnell at trustwave.com>, CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>,
> CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject: *RE: [Servercert-wg] Ballot SC4 - email and CAA CONTACT
>
>
>
> I’d like not to make it more complicated than necessary, but if there are
> useful clarifications you can suggest about how better to define “valid”,
> I’m all ears.
>
>
>
> For the particular concern you mentioned, it seems clear to me that an
> Internationalized Email Address is in fact a valid email address for method
> 14 (assuming it is not invalid for some other reason).
>
>
>
> -Tim
>
>
>
> *From:* Corey Bonnell <CBonnell at trustwave.com>
> *Sent:* Tuesday, August 7, 2018 10:35 AM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>;
> CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [Servercert-wg] Ballot SC4 - email and CAA CONTACT
>
>
>
> Hi Tim,
>
> I think this updated text is fine (with one caveat about raw addresses;
> see below), pending changing “domain being validated” to “Authorization
> Domain Name” to be consistent with other changes of this usage in the
> ballot.
>
>
>
> If the TXT record data is merely the raw email address (as opposed to a
> mailto: URL), it would be good to specify more concretely what “valid”
> means. This is especially relevant in regard to Internationalized Email
> Addresses (and the potential can of worms that entails) and whether or not
> they’re considered “valid” for method 14.
>
>
>
> Thanks,
>
> Corey
>
>
>
> *From: *Tim Hollebeek <tim.hollebeek at digicert.com>
> *Date: *Friday, August 3, 2018 at 4:57 PM
> *To: *Corey Bonnell <CBonnell at trustwave.com>, CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>,
> CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject: *RE: [Servercert-wg] Ballot SC4 - email and CAA CONTACT
>
>
>
> Corey,
>
>
>
> Upon further review, I believe the domain-authorization-email is a relic
> of a previous proposal, and could be safely removed.
>
>
>
> The DNS TXT record MUST be placed on the "_caa_contact_email" subdomain of
> the domain being validated.  The entire RDATA value of the
> "_caa_contact_email" record MUST be a valid email address, with no
> additional padding or structure, or it cannot be used.
>
>
>
> ?
>
>
>
> -Tim
>
>
>
> *From:* Corey Bonnell <CBonnell at trustwave.com>
> *Sent:* Friday, August 3, 2018 1:44 PM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>;
> CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [Servercert-wg] Ballot SC4 - email and CAA CONTACT
>
>
>
> Given that the entire RDATA is the email address, I don’t see how “The DNS
> record MUST be named "domain-authorization-email"” is applicable here, as
> there is nowhere in the RDATA to specify the name.
>
>
>
> Also, is the RDATA a mailto: URL (as in the CAA record), or is it a plain
> email address? I’d imagine the former would be preferable for parity with
> the CAA syntax as well as reuse of the “_caa_contact” attribute leaf for
> phone numbers.
>
>
>
> Thanks,
>
> Corey
>
>
>
> *From: *Tim Hollebeek <tim.hollebeek at digicert.com>
> *Date: *Friday, August 3, 2018 at 12:19 PM
> *To: *Corey Bonnell <CBonnell at trustwave.com>, CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>,
> CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject: *RE: [Servercert-wg] Ballot SC4 - email and CAA CONTACT
>
>
>
> I expect the email address would be the entirety of the RDATA for the RR,
> with no additional formatting.  I can make that explicit if you think it
> would be helpful.
>
>
>
> -Tim
>
>
>
> *From:* Corey Bonnell <CBonnell at trustwave.com>
> *Sent:* Friday, August 3, 2018 12:04 PM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>;
> CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [Servercert-wg] Ballot SC4 - email and CAA CONTACT
>
>
>
> Hi Tim,
>
> Can you provide an example of how a TXT record would be formatted to
> convey the email address (as was done for the CAA records)? It’s not clear
> to me based on the description given.
>
>
>
> Thanks,
>
>
>
> *Corey Bonnell*
>
> Senior Software Engineer
>
>
>
> *Trustwave* | SMART SECURITY ON DEMAND
> https://www.trustwave.com <http://www.trustwave.com/>
>
>
>
> *From: *Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of
> Tim Hollebeek via Servercert-wg <servercert-wg at cabforum.org>
> *Reply-To: *Tim Hollebeek <tim.hollebeek at digicert.com>, CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> *Date: *Friday, August 3, 2018 at 11:50 AM
> *To: *CA/Browser Forum Public Discussion List <public at cabforum.org>, "
> servercert-wg at cabforum.org" <servercert-wg at cabforum.org>
> *Subject: *[Servercert-wg] Ballot SC4 - email and CAA CONTACT
>
>
>
>
>
> Ballot SC4: 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: Domain Owner Email in CAA
>
> 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 the CAA Contact property
> record of the Authorization Domain Name 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 ADN 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: Domain Owner Email published in TXT record
>
>
>
> 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 the DNS TXT record of the
> Authorization Domain Name in the format 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 ADN 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: 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 type SHOULD be implemented:
>
> mailto: An SMTP email address where the domain holder or other authorized
> party can be contacted.
>
>
>
> Schemes other than "mailto:" MUST NOT 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://scanmail.trustwave.com/?c=4062&d=yLPp2wo1WgGIYigK9OLlFaUXGubLU6Sxlag77nB0Rg&s=5&u=http%3a%2f%2fexample%2ecom>
>
> .              CAA 0 issue “ca.example.net”
>
> .              CAA 0 contact “mailto:domainowner at example.com
> <domainowner at example.com>”
>
>
>
> Support for Legacy Systems
>
>
>
> Some systems still do not have sufficient support for CAA records.  To
> allow users of those systems to specify contact information, a legacy
> format using text records is allowed.
>
>
>
> The DNS TXT record MUST be placed on the "_caa_contact" subdomain of the
> domain being validated.  The DNS record MUST be named
> "domain-authorization-email".  The value of "domain-authorization-email"
> MUST contain a valid email address, 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&expand=1
> <https://scanmail.trustwave.com/?c=4062&d=yLPp2wo1WgGIYigK9OLlFaUXGubLU6Sxlfs35CVxQA&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2fcompare%2fBallot-SC4---CAA-CONTACT-email%3fdiff%3dunified%26amp%3bexpand%3d1>
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
>
> Start Time: 2018-08-03 11:50 Eastern
>
> End Time: Not before 2018-08-10 11:50 Eastern
>
> Vote for approval (7 days)
>
> Start Time: TBD
>
> End Time: TBD
> _______________________________________________
> Servercert-wg mailing list
> 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/20180807/22dff7e1/attachment-0001.html>