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

["Salz, Rich" <[e-mail]>]

Hugo just submitted a draft (Thanks!) that does this.

I don’t think we need to reset the clock, and will continue with advancing this.

From: Tim Hollebeek <[e-mail]>
Date: Thursday, June 21, 2018 at 1:42 PM
To: Rich Salz <[e-mail]>, "[e-mail]" <[e-mail]>, Ryan Sleevi <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Hugo Landau <[e-mail]>, Roland Shoemaker <[e-mail]>
Subject: RE: [Acme] Handling non-conformant CAA property names in ACME-CAA

I agree with Ryan that that’s probably the best way forward, if changing the names to remove the hyphens doesn’t cause undue hardship.

-Tim

From: Salz, Rich [mailto:[e-mail]]
Sent: Thursday, June 21, 2018 9:07 AM
To: Tim Hollebeek <[e-mail]>; Ivan Ristic <[e-mail]>; Ryan Sleevi <[e-mail]>
Cc: IETF ACME <[e-mail]>; Hugo Landau <[e-mail]>; Roland Shoemaker <[e-mail]>
Subject: Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

It seems the quickest way to address this is to remove the hyphens from the labels and continue progressing the doc.

Hugo, can you do this in the next few days, or should we (chairs) find someone else?

From: Tim Hollebeek <[e-mail]<mailto:[e-mail]>>
Date: Thursday, June 21, 2018 at 8:30 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Ryan Sleevi <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Hugo Landau <[e-mail]<mailto:[e-mail]>>, Roland Shoemaker <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

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

From: Acme [mailto:[e-mail]] On Behalf Of Ivan Ristic
Sent: Thursday, June 21, 2018 3:41 AM
To: Ryan Sleevi <[e-mail]<mailto:[e-mail]>>
Cc: IETF ACME <[e-mail]<mailto:[e-mail]>>; Hugo Landau <[e-mail]<mailto:[e-mail]>>; Roland Shoemaker <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

Just to add to this, those CAs whose CAA processing follows the current spec will likely see all CAA policies with ACME-CAA extensions as invalid, potentially leading to operational issues. It's going to be the same with tools that inspect and validate CAA (e.g., our tool, Hardenize).

On Wed, Jun 20, 2018 at 10:25 PM, Ryan Sleevi <[e-mail]<mailto:[e-mail]>> wrote:
On Wed, Jun 20, 2018 at 4:47 PM, Roland Shoemaker <[e-mail]<mailto:[e-mail]>> wrote:
As previously discussed on the list the two property names defined in draft-ietf-acme-caa, "validation-methods” and "account-uri”, do not conform to the ABNF syntax in RFC 6844 as they contain hyphens. 6844-bis fixes this by expanding the ABNF to be less restrictive but for now this doesn’t really address the problem at hand.

Given it is probably unlikely that 6844-bis will be standardized any time soon is there any plan to make changes to draft-ietf-acme-caa to address this in the short term? Given we are not yet at the point where there is wide deployment/adoption of this feature can we take the easy route and simply remove the hyphens so that the document at least complies with the existing CAA document?

It is not just that -bis would need to be finalized and standardized, but that CAs would also have to adopt and recognize the syntax in -bis, updating their 6844 implementations. Even if -bis were final tomorrow, that would still take considerable time, given the normative differences, and so I think aligning on an inter-operable expression is certainly preferable, allowing it to work with both 6844 and -bis.

_______________________________________________
Acme mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/acme



--
Ivan