Please feel free to provide feedback on GitHub and use GitHub to suggest changes, even if the GitHub version isn’t the official ballot version. I actually think it’s much easier to collaboratively work on text there. Or suggestions on this thread are fine too. I’m fine with whatever works best for people.
Some of your suggestions are very helpful. I’ll look more closely at them when I have a bit more time and am typing on a more stable surface. -Tim From: Ryan Sleevi <[email protected]> Sent: Monday, August 6, 2018 10:37 AM To: Wayne Thayer <[email protected]>; [email protected] Cc: Tim Hollebeek <[email protected]>; CABFPub <[email protected]> Subject: Re: [Servercert-wg] Ballot SC4 - email and CAA CONTACT Tim, Thanks for sending this around. As mentioned in our NO vote, there's still a lot of opportunity to improve here. I'd like to revisit whether this makes sense to split into CAA and TXT ballots separately - it seems that splitting this may resolve some of the technical challenges, and allow a more proper discussion about the relative merits. This is especially important given the tradeoffs between the TXT and CAA methods. Given the warning you've placed on the Github version, it's unclear whether you're opposed to receiving feedback through that mechanism. I'm hoping you can clarify. The lack of a pull request suggests you would NOT like feedback to be echo'd on GitHub, where it can be more clearly provided. > 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. Suggestion: As .13 and .14 define different validation methods, these should be separate appendices. This especially is to avoid confusion related to the domain hierarchy (captured later in this email) > Each email MAY confirm control of multiple FQDNs, provided the email address > used is a DNS contact email address for each ADN being validated. I think this is ambiguous as to the intent. One reading of this is to suggest that every ADN must use the same method (e.g. "published in DNS"), while another reading may suggest allowing some permutation or set of combinations for validation (e.g. 3.2.2.4.13, 3.2.2.4.2, 3.2.2.4.14). This is due to the ambiguity of the term "DNS contact email address", and its reuse within both sections .13 and .14 (but omission from .2 and .4). What's the expected set of combinations permitted, and then we can figure out how to clarify that with the language? > 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. The text provided deviates from 3.2.2.4.2 and 3.2.2.4.4 for non-obvious reasons, including one subtle but potentially meaningful change. On a formatting perspective, you've reformatted this language, making it harder to compare the two for differences. Had they been aligned, it might be clearer that the phrase "in which case, the CA MUST follow its CPS" has been omitted from this section as compared to the other sections. Was that intentional? Appendix B: > An SMTP email address I believe this is attempting to borrow from the language of RFC 6844, but unfortunately conflates some terms to create a new one. RFC 6844 states that "an SMTP email that is submitted to the mail address specified.". Notably, the term here is mail address, and the mechanism for delivering to that address is SMTP within 6844. You'll find the phrase "SMTP email address" does not appear in any IETF documents, whereas the term used by most documents that are meaning to indicate this are noted as "Internet mail address", reflecting the language in RFC 5322 which defines "The Internet addr-spec address" in section 3.4.1. Regarding TXT, there's several issues that I think merit separating out these ballots, in order to achieve the desired expediency in adoption (of at least the CAA method) 1) Structurally, this has the same issues of SHA-1 and RSA-1024 - namely, it sets out a claim "Some systems still do not have sufficient support for CAA records", without describing a system for measuring or quantifying that support. As we saw with "some systems do not support SHA-1", setting forth a claim like this - without a means to quantify - quickly sets it up for cargo culting and superstition. If the goal is to ensure that this remains 'legacy', then we should have some means to quantify these systems, as well as provide more proactive measurements to address these. For example, if a customer supports CAA, but chooses to use TXT, is it a violation? Why or why not? As discussed previously, requiring concrete information - either from the Applicant or the CA - to assess claims of legacy support is vital to being able to eventually retire this method, in favor of its more well-specified alternative. I thought it best to first pose this position, to see if we're in agreement about the concerns and goals, before attempting to propose text for a solution. 2) The format of the record is ambiguous. One reading is to think that a TXT record exists at _caa_contact that uses the "attr=val" format of RFC 1464, namely: _caa_contact.example.com <http://caa_contact.example.com> IN TXT "[email protected] <mailto:[email protected]> " Another reading is to think that the TXT record exists outside the constraints suggested of RFC 1464, and instead is domain-authorization-email._caa_contact.example.com <http://caa_contact.example.com> IN TXT "[email protected] <mailto:[email protected]> " One way to reduce this ambiguity is by consistently using the terminology from RFC 7719. For example, if the latter interpretation is intended, "The DNS TXT record label MUST be named "domain-authorization-email", and MUST be a subdomain of the "_caa_contact" subdomain of the FQDN being validated." 3) If the latter interpretation is correct, this would be the first method that permits validation at two levels deeper than the FQDN (namely, "domain-authorization-email._caa_contact.FQDN") versus the other methods, that only permit 0-or-1 levels deeper (either CAA/CNAME or "label.FQDN" for TXT). The implications of this to existing systems seems... under-documented, at best, considering that it can lead to new issuance. What investigations have you done to ensure that this is safe for existing systems, and what outreach to domain operators has been done? As was shown with .9 and .10, it's entirely possible that this design is fundamentally insecure in its assumptions, so understanding what evidence exists of its reasonableness is important. On Fri, Aug 3, 2018 at 5:05 PM Wayne Thayer via Servercert-wg <[email protected] <mailto:[email protected]> > wrote: On Fri, Aug 3, 2018 at 2:01 PM Tim Hollebeek <[email protected] <mailto:[email protected]> > wrote: Does changing that noun phrase to Authorization Domain Name address your concern? Yes, that fixes the issue. _______________________________________________ Servercert-wg mailing list [email protected] <mailto:[email protected]> http://cabforum.org/mailman/listinfo/servercert-wg
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
