<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 8, 2017 at 4:17 AM, Gervase Markham <span dir="ltr"><<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 13/01/17 17:36, Ryan Sleevi wrote:<br>
> On Fri, Jan 13, 2017 at 7:23 AM, Gervase Markham via Public<br>
</span><span class="">> <<a href="mailto:public@cabforum.org">public@cabforum.org</a> <mailto:<a href="mailto:public@cabforum.org">public@cabforum.org</a>>> wrote:<br>
><br>
> > Text proposals welcome.<br>
><br>
> CAs MUST support the issue, issuewild, and iodef property tags.<br>
> Additional property tags MAY be supported, but MUST NOT conflict with or<br>
> supersede the mandatory property tags set out in this document. CAs MUST<br>
> respect the critical flag and reject any unrecognized properties with<br>
> this set.<br>
<br>
</span>That seems fine, except that at the moment, iodef support (as in,<br>
actually sending something to the endpoint) is a SHOULD, not a MUST. Do<br>
we want to keep it as a SHOULD?<br></blockquote><div><br></div><div>Perhaps "CAs MUST support" should be "When processing CAA records, CAs MUST process the issue, issuewild, and iodef tags as specified in RFC 6844." </div><div><br></div><div>I realize that's a mouthful, but I'm trying to capture the same expression of what the 'critical' flag means in both X.509 and RFC 6844 - that is, it's a requirement that you recognize and process the semantics relative to whatever specification defined them.</div><div><br></div><div>This is hopefully uncontroverisal. For example, many relying parties _recognize_ the authorityInfoAccess extension, but that doesn't mean they MUST fetch the id-ad-caIssuers URL. Similarly, for iodef, CAs MUST recognize the semantics of such a field (that is, they MUST NOT fail if it is indicated as critical), but as RFC 6844 clearly indicates its a MAY for reporting, that doesn't mean that CAs have to send reports.</div><div><br></div><div>I realize that was ambiguous with my wording of "support"; I've tried to see if 'process' clears up the ambiguity between "parse" and "send a report"</div><div><br></div><div>Alternatively, it seems very well that we should argue that CAs MUST support iodef for the two main methods (http and mailto) so that DNS holders can be notified of any attempted misissuance. For example, if Google places a CAA record on its domains to indicate Symantec (or Symantec-issued sub-CAs), but a customer of Google (or unauthorized employee) is somehow able to authenticate a request according to the methods of 3.2.2.4 (e.g. perhaps due to a Google bug, perhaps due to a CA bug), receiving an iodef alert to this seems valuable to the ecosystem at large.</div><div><br></div><div>However, I'm happy to treat the discussion of iodef separate from the main CAA ballot, which is why I've proposed the language above that for now tries to capture the "You need to process these fields as specified by the RFC; you need to fail unrecognized fields as specified by the RFC"</div></div></div></div>