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

Mon Aug 27 08:51:42 MST 2018

Tim,

Has there been an update to the ballot?

Similarly, has there been any effort to address the TXT deprecation, or the
use of multiple layers of subdomains?

On Thu, Aug 16, 2018 at 10:35 AM Tim Hollebeek via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Thanks Corey.  This is very helpful.  I’ll update the ballot.
>
>
>
> -Tim
>
>
>
> *From:* Corey Bonnell <CBonnell at trustwave.com>
> *Sent:* Thursday, August 9, 2018 11:04 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
>
>
>
> Tim,
>
> There are additional concerns, namely regarding the character set encoding
> (as in UTF-8, UTF-16, Shift-JIS, etc.). A TXT record could conceivably
> contain a Shift-JIS-encoded (or some other character set) email address
> which may be treated as “valid” by a CA (who then sends an email to the
> Shift-JIS-encoded email address). However, when the TXT record RDATA is
> interpreted as UTF-8 by another CA, this will yield another email address,
> allowing an attacker to setup a mailbox to receive the DV email. Given
> this, I do not believe I am being overly pedantic in asking that we more
> concretely define what “valid” means.
>
>
>
> Given that I’ve seen at least one certificate in CT that had various
> Subject RDN values be encoded in UTF-16 (where UTF-16 isn’t even allowed),
> I believe this scenario is very likely to occur. Explicitly specifying what
> “valid” means by referencing RFC 6532 section 3.2 will provide guidance to
> the ecosystem to mitigate this risk. My suggested wording is to change “valid
> email address, with no additional padding or structure” to “valid email
> address as defined in RFC 6532 section 3.2, with no additional padding or
> structure”.
>
>
>
> That being said, I think there’s significant value in aligning the syntax
> of the CAA and TXT record. Specifying a single syntax makes it less
> cumbersome for Applicants, CA engineers and support personnel, and DNS
> providers who will likely author tools to generate these records. I agree
> with you that using the proposed TXT “valid email address” (with the
> addition of a reference to RFC 6532 to define “valid”) is preferable over
> mailto: for the reasons that you mentioned, provided that it’s used for
> both the CAA record (whose property tag would probably need to be renamed
> to “contactemail” or something similar) and TXT record.
>
>
>
> Thanks,
>
> Corey
>
>
>
> *From: *Tim Hollebeek <tim.hollebeek at digicert.com>
> *Date: *Tuesday, August 7, 2018 at 7:29 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
>
>
>
> 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.
>
>
>
> 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
> <https://scanmail.trustwave.com/?c=4062&d=vavq28pjHFI2ph_WoO8TpMTD8JkSCWk7cxp_KdSnIA&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc6068%23section-2>)
> differs from an email address encoded as specified in RFC 6532, section 3.2
> (https://tools.ietf.org/html/rfc6532#section-3.2
> <https://scanmail.trustwave.com/?c=4062&d=vavq28pjHFI2ph_WoO8TpMTD8JkSCWk7cxwletXyeg&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc6532%23section-3%2e2>).
> 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=vavq28pjHFI2ph_WoO8TpMTD8JkSCWk7c08pedHzeg&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=vavq28pjHFI2ph_WoO8TpMTD8JkSCWk7cxwlc4T2fA&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/20180827/21f6385c/attachment-0001.html>