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-ietf@sleevi.com> wrote:

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

-- 
Ivan