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:rs...@akamai.com] 
Sent: Thursday, June 21, 2018 9:07 AM
To: Tim Hollebeek <tim.holleb...@digicert.com>; Ivan Ristic 
<ivan.ris...@gmail.com>; Ryan Sleevi <ryan-i...@sleevi.com>
Cc: IETF ACME <acme@ietf.org>; Hugo Landau <hlan...@devever.net>; Roland 
Shoemaker <rol...@letsencrypt.org>
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 <tim.holleb...@digicert.com 
<mailto:tim.holleb...@digicert.com> >
Date: Thursday, June 21, 2018 at 8:30 AM
To: "ivan.ris...@gmail.com <mailto:ivan.ris...@gmail.com> " 
<ivan.ris...@gmail.com <mailto:ivan.ris...@gmail.com> >, Ryan Sleevi 
<ryan-i...@sleevi.com <mailto:ryan-i...@sleevi.com> >
Cc: "acme@ietf.org <mailto:acme@ietf.org> " <acme@ietf.org 
<mailto:acme@ietf.org> >, Hugo Landau <hlan...@devever.net 
<mailto:hlan...@devever.net> >, Roland Shoemaker <rol...@letsencrypt.org 
<mailto:rol...@letsencrypt.org> >
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:acme-boun...@ietf.org] On Behalf Of Ivan Ristic
Sent: Thursday, June 21, 2018 3:41 AM
To: Ryan Sleevi <ryan-i...@sleevi.com <mailto:ryan-i...@sleevi.com> >
Cc: IETF ACME <acme@ietf.org <mailto:acme@ietf.org> >; Hugo Landau 
<hlan...@devever.net <mailto:hlan...@devever.net> >; Roland Shoemaker 
<rol...@letsencrypt.org <mailto:rol...@letsencrypt.org> >
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 <ryan-i...@sleevi.com 
<mailto:ryan-i...@sleevi.com> > wrote:

On Wed, Jun 20, 2018 at 4:47 PM, Roland Shoemaker <rol...@letsencrypt.org 
<mailto:rol...@letsencrypt.org> > 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
Acme@ietf.org <mailto:Acme@ietf.org> 
https://www.ietf.org/mailman/listinfo/acme





 

-- 

Ivan

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Reply via email to