On Tue, Aug 7, 2018 at 7:29 PM Tim Hollebeek via Servercert-wg < [email protected]> 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 <[email protected]> > *Sent:* Tuesday, August 7, 2018 3:32 PM > *To:* Tim Hollebeek <[email protected]>; CA/B Forum Server > Certificate WG Public Discussion List <[email protected]>; > CA/Browser Forum Public Discussion List <[email protected]> > *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 [email protected] in > mailto:[email protected] <[email protected]>). 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 <[email protected]> > *Date: *Tuesday, August 7, 2018 at 10:59 AM > *To: *Corey Bonnell <[email protected]>, CA/B Forum Server > Certificate WG Public Discussion List <[email protected]>, > CA/Browser Forum Public Discussion List <[email protected]> > *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 <[email protected]> > *Sent:* Tuesday, August 7, 2018 10:35 AM > *To:* Tim Hollebeek <[email protected]>; CA/B Forum Server > Certificate WG Public Discussion List <[email protected]>; > CA/Browser Forum Public Discussion List <[email protected]> > *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 <[email protected]> > *Date: *Friday, August 3, 2018 at 4:57 PM > *To: *Corey Bonnell <[email protected]>, CA/B Forum Server > Certificate WG Public Discussion List <[email protected]>, > CA/Browser Forum Public Discussion List <[email protected]> > *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 <[email protected]> > *Sent:* Friday, August 3, 2018 1:44 PM > *To:* Tim Hollebeek <[email protected]>; CA/B Forum Server > Certificate WG Public Discussion List <[email protected]>; > CA/Browser Forum Public Discussion List <[email protected]> > *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 <[email protected]> > *Date: *Friday, August 3, 2018 at 12:19 PM > *To: *Corey Bonnell <[email protected]>, CA/B Forum Server > Certificate WG Public Discussion List <[email protected]>, > CA/Browser Forum Public Discussion List <[email protected]> > *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 <[email protected]> > *Sent:* Friday, August 3, 2018 12:04 PM > *To:* Tim Hollebeek <[email protected]>; CA/B Forum Server > Certificate WG Public Discussion List <[email protected]>; > CA/Browser Forum Public Discussion List <[email protected]> > *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 <[email protected]> on behalf of > Tim Hollebeek via Servercert-wg <[email protected]> > *Reply-To: *Tim Hollebeek <[email protected]>, CA/B Forum Server > Certificate WG Public Discussion List <[email protected]> > *Date: *Friday, August 3, 2018 at 11:50 AM > *To: *CA/Browser Forum Public Discussion List <[email protected]>, " > [email protected]" <[email protected]> > *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:[email protected] > <[email protected]>” > > > > 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 > [email protected] > http://cabforum.org/mailman/listinfo/servercert-wg >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
