Subject: [Acme] Let's Encrypt ACME-CAA validation-methods support

From: Daniel McCarney <[email-masked]>
Date: Wed, 30 May 2018 13:57:18 -0400

Hi folks,

I'm happy to share that Let's Encrypt has deployed support for Hugo
Landau's ACME-CAA "validation-methods" CAA record extension in the staging
environment[0]. Community feedback/review would be most appreciated.

You can find more information in the associated API announcement[1].

Thanks,

- Daniel / cpu

[0] - https://letsencrypt.org/docs/staging-environment/
[1] -
https://community.letsencrypt.org/t/acme-caa-validation-methods-support/63125

---

From: Corey Bonnell <[email-masked]>
Date: Wed, 30 May 2018 19:17:40 +0000

Hello,
This development is exciting work in regard to allowing domain owners to limit which validation methods they want to allow to be used for their domains.

Unfortunately, the validation-methods extension is not compliant with RFC 6844 (the CAA RFC), as parameter tags cannot contain hyphens.  This was originally pointed out on this mailing list in January (https://www.ietf.org/mail-archive/web/acme/current/msg02506.html). I proposed a fix to this issue (as well as fixing an ambiguity in the ABNF grammar in regard to parameter delimiters) on the LAMPS WG mailing list a few months ago (https://www.ietf.org/mail-archive/web/spasm/current/msg01144.html), but this change has not yet been incorporated into a draft of RFC 6844-bis.

Since RFC 6844 dictates that parameters have meaning specific to the issuer (from section 5.1: “The semantics of issuer-parameters are determined by the issuer alone”), I don’t believe that issuing certificates for domains whose CAA record sets contain non-conformant parameter syntax would constitute mis-issuance. However, it may present difficulties in regard to tooling/automation that expect all parameter tags to follow RFC 6844.

Thanks,

Corey Bonnell
Senior Software Engineer

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>

From: Acme <[email-masked]> on behalf of Daniel McCarney <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Wednesday, May 30, 2018 at 1:57 PM
To: Hugo Landau <[email-masked]>, IETF ACME <[email-masked]>
Subject: [Acme] Let's Encrypt ACME-CAA validation-methods support

Hi folks,

I'm happy to share that Let's Encrypt has deployed support for Hugo Landau's ACME-CAA "validation-methods" CAA record extension in the staging environment[0]. Community feedback/review would be most appreciated.

Thanks,

- Daniel / cpu
[0] - https://letsencrypt.org/docs/staging-environment/<https://scanmail.trustwave.com/?c=4062&d=k-aO27uBtMDYKMre1tiXIgJYkioPrIC1cToq5JsZWQ&s=5&u=https%3a%2f%2fletsencrypt%2eorg%2fdocs%2fstaging-environment%2f>
[1] - https://community.letsencrypt.org/t/acme-caa-validation-methods-support/63125<https://scanmail.trustwave.com/?c=4062&d=k-aO27uBtMDYKMre1tiXIgJYkioPrIC1cWBx5cxLDw&s=5&u=https%3a%2f%2fcommunity%2eletsencrypt%2eorg%2ft%2facme-caa-validation-methods-support%2f63125>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 30 May 2018 12:19:11 -0700

Apologies for the delay on publishing the latest draft. I'll work on 
getting that out today. Thanks for the reminder!

On 05/30/2018 12:17 PM, Corey Bonnell wrote:
>
> Hello,
>
> This development is exciting work in regard to allowing domain owners 
> to limit which validation methods they want to allow to be used for 
> their domains.
>
> Unfortunately, the validation-methods extension is not compliant with 
> RFC 6844 (the CAA RFC), as parameter tags cannot contain hyphens. 
>  This was originally pointed out on this mailing list in January 
> (https://www.ietf.org/mail-archive/web/acme/current/msg02506.html). I 
> proposed a fix to this issue (as well as fixing an ambiguity in the 
> ABNF grammar in regard to parameter delimiters) on the LAMPS WG 
> mailing list a few months ago 
> (https://www.ietf.org/mail-archive/web/spasm/current/msg01144.html), 
> but this change has not yet been incorporated into a draft of RFC 
> 6844-bis.
>
> Since RFC 6844 dictates that parameters have meaning specific to the 
> issuer (from section 5.1: “The semantics of issuer-parameters are 
> determined by the issuer alone”), I don’t believe that issuing 
> certificates for domains whose CAA record sets contain non-conformant 
> parameter syntax would constitute mis-issuance. However, it may 
> present difficulties in regard to tooling/automation that expect all 
> parameter tags to follow RFC 6844.
>
> Thanks,
>
> *Corey Bonnell*
>
> Senior Software Engineer
>
> *Trustwave***| SMART SECURITY ON DEMAND
> www.trustwave.com <http://www.trustwave.com/>
>
> *From: *Acme <[email-masked]> on behalf of Daniel McCarney 
> <[email-masked]>
> *Reply-To: *"[email-masked]" <[email-masked]>
> *Date: *Wednesday, May 30, 2018 at 1:57 PM
> *To: *Hugo Landau <[email-masked]>, IETF ACME <[email-masked]>
> *Subject: *[Acme] Let's Encrypt ACME-CAA validation-methods support
>
> Hi folks,
>
> Landau's ACME-CAA "validation-methods" CAA record extension in the 
> staging environment[0]. Community feedback/review would be most 
> appreciated.
>
> <https://scanmail.trustwave.com/?c=4062&d=k-aO27uBtMDYKMre1tiXIgJYkioPrIC1cToq5JsZWQ&s=5&u=https%3a%2f%2fletsencrypt%2eorg%2fdocs%2fstaging-environment%2f>
>
> [1] - 
> <https://scanmail.trustwave.com/?c=4062&d=k-aO27uBtMDYKMre1tiXIgJYkioPrIC1cWBx5cxLDw&s=5&u=https%3a%2f%2fcommunity%2eletsencrypt%2eorg%2ft%2facme-caa-validation-methods-support%2f63125>
>
>
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme