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

From: Roland Shoemaker <[email-masked]>
Date: Wed, 20 Jun 2018 13:47:15 -0700

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?

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 20 Jun 2018 17:25:18 -0400

On Wed, Jun 20, 2018 at 4:47 PM, Roland Shoemaker <[email-masked]>
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.

---

From: Ivan Ristic <[email-masked]>
Date: Thu, 21 Jun 2018 08:40:48 +0100

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 <[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

-- 
Ivan

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 21 Jun 2018 12:30:08 +0000

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:[email-masked]] On Behalf Of Ivan Ristic
Sent: Thursday, June 21, 2018 3:41 AM
To: Ryan Sleevi <[email-masked]>
Cc: IETF ACME <[email-masked]>; Hugo Landau <[email-masked]>; Roland Shoemaker <[email-masked]>
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 <[email-masked] <mailto:[email-masked]> > wrote:

On Wed, Jun 20, 2018 at 4:47 PM, Roland Shoemaker <[email-masked] <mailto:[email-masked]> > wrote:

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
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/acme

-- 

Ivan

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 21 Jun 2018 10:51:58 -0400

On Thu, Jun 21, 2018 at 8:30 AM, Tim Hollebeek <[email-masked]>
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.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 21 Jun 2018 15:06:38 +0000

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 <[email-masked]>
Date: Thursday, June 21, 2018 at 8:30 AM
To: "[email-masked]" <[email-masked]>, Ryan Sleevi <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Hugo Landau <[email-masked]>, Roland Shoemaker <[email-masked]>
Subject: Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

-Tim

On Wed, Jun 20, 2018 at 10:25 PM, Ryan Sleevi <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Jun 20, 2018 at 4:47 PM, Roland Shoemaker <[email-masked]<mailto:[email-masked]>> 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.

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

--
Ivan

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 21 Jun 2018 17:42:23 +0000

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:[email-masked]] 
Sent: Thursday, June 21, 2018 9:07 AM
To: Tim Hollebeek <[email-masked]>; Ivan Ristic <[email-masked]>; Ryan Sleevi <[email-masked]>
Cc: IETF ACME <[email-masked]>; Hugo Landau <[email-masked]>; Roland Shoemaker <[email-masked]>
Subject: Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

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

-Tim

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

 

-- 

Ivan

---

From: Hugo Landau <[email-masked]>
Date: Thu, 21 Jun 2018 19:57:25 +0100

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

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 22 Jun 2018 17:59:20 +0000

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 <[email-masked]>
Date: Thursday, June 21, 2018 at 1:42 PM
To: Rich Salz <[email-masked]>, "[email-masked]" <[email-masked]>, Ryan Sleevi <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Hugo Landau <[email-masked]>, Roland Shoemaker <[email-masked]>
Subject: RE: [Acme] Handling non-conformant CAA property names in ACME-CAA

-Tim

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

-Tim

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

--
Ivan