> Hi Jacob,
> Perhaps not as elegant and concise, but a workaround would be to temporarily
> (until 6844-bis gets incorporated into the Baseline Requirements) prohibit
> multiple parameters in the same CAA record and instead require that multiple
> parameters span multiple issue/issuewild
: [Acme] Handling non-conformant CAA property names in ACME-
> CAA
>
> There's a similar issue for parameters: RFC 6844 section 3 says each name-
> value pair is separated by a semicolon:
>
> https://tools.ietf.org/html/rfc6844#section-3
> >issue [; = ]* : The issue pro
Hi Jacob,
Perhaps not as elegant and concise, but a workaround would be to temporarily
(until 6844-bis gets incorporated into the Baseline Requirements) prohibit
multiple parameters in the same CAA record and instead require that multiple
parameters span multiple issue/issuewild records with
There's a similar issue for parameters: RFC 6844 section 3 says each
name-value pair is separated by a semicolon:
https://tools.ietf.org/html/rfc6844#section-3
> issue [; = ]* : The issue property
RFC 6844 section 5.2 says each name-value pair is separated by a space:
Hugo Landau , Roland
Shoemaker
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:rs...@akamai.com]
Sen
> 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?
Done.
___
Acme mailing list
; Hugo Landau ; Roland
Shoemaker
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
On Thu, Jun 21, 2018 at 8:30 AM, Tim Hollebeek
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
] 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
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
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
11 matches
Mail list logo
