Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

[Ryan Sleevi <[e-mail]>]

On Thu, Jun 21, 2018 at 8:30 AM, Tim Hollebeek <[e-mail]>
wrote:

> The current ABNF in 6844 is basically broken, and doesn’t express what it
> was intended to express.  I remember staring at it with Corey and wondering
> how it got approved …
>

>
> So while I’m not particularly picky on the exact bureaucratic details of
> how a fix gets made, it would be nice to get this resolved quickly via an
> errata or whatever.  There are a bunch of reasonable extensions to CAA that
> could be made in the future, and a solid and agreed-upon grammar is a
> necessary prerequisite.
>
>
>
> Another option (at least for uses on the Web PKI) is clarification by CABF
> ballot.  Despite all the downsides of CABF, it does have the ability to
> move pretty quickly when it needs to.
>
>
>
> -Tim
>

I would like to focus on resolving the issues with the document, as
written, as it specifies a grammar not conformant with 6844.

I disagree with your assessments about intent, brokenness, or possible
solutions for 6844 - but those are all better for LAMPS to work out, and we
can have that reasonable debate there. I hope, though, we're in agreement
that conforming implementations of 6844 cannot and should not process these
records, and as Ivan calls out, runs real operational risk to users that
rely on them. Let's fix that, now, and worry about whether or not we can
break compatibility in a -bis document and whether it's worth it.