[cabfpub] Draft CAA motion (3)

[Ryan Sleevi]

On Wed, Feb 8, 2017 at 4:17 AM, Gervase Markham <gerv at mozilla.org> wrote:

> On 13/01/17 17:36, Ryan Sleevi wrote:
> > On Fri, Jan 13, 2017 at 7:23 AM, Gervase Markham via Public
> > <public at cabforum.org <mailto:public at cabforum.org>> wrote:
> >
> > > Text proposals welcome.
> >
> > CAs MUST support the issue, issuewild, and iodef property tags.
> > Additional property tags MAY be supported, but MUST NOT conflict with or
> > supersede the mandatory property tags set out in this document. CAs MUST
> > respect the critical flag and reject any unrecognized properties with
> > this set.
>
> That seems fine, except that at the moment, iodef support (as in,
> actually sending something to the endpoint) is a SHOULD, not a MUST. Do
> we want to keep it as a SHOULD?
>

Perhaps "CAs MUST support" should be "When processing CAA records, CAs MUST
process the issue, issuewild, and iodef tags as specified in RFC 6844."

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.

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.

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"

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.

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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170208/7d87c3aa/attachment-0002.html>