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

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 9 Jul 2018 17:57:01 -0700

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 <Issuer Domain Name> [; <name>=<value> ]* :  The issue property

RFC 6844 section 5.2 says each name-value pair is separated by a space:

https://tools.ietf.org/html/rfc6844#section-5.2
 >    issuevalue  = space [domain] space [";" *(space parameter) space]

For 6844-bis, in the LAMPS WG, we concluded that the latter was most 
likely an error in the ABNF, and that semicolons were preferable:

https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-00#section-5.2
 >    parameters = (parameter *WSP ";" *WSP parameters) / parameter

ACME-CAA's examples use semicolons:

https://tools.ietf.org/html/draft-ietf-acme-caa-03#appendix-A
 > example.com. IN CAA 0 issue "example.net; \
 >     account-uri=https://example.net/account/1234; \
 >     validation-methods=dns-01"

We resolved the hyphen question on the basis of interoperability: Some 
DNS UIs rejected setting CAA records with hyphens in property names, so 
we did the simple thing and removed them.

The semicolon question is not so easily solved. There is no unambiguous 
reading of RFC 6844, no reason to consider section 3 more normative than 
section 5.2 or vice versa.

I have one piece of interop data: While Route53 rejected hyphens in 
property names, it accepts semicolons separating name-value pairs.

My preference is for ACME-CAA to continue follow the RFC 6844bis 
interpretation. What are others' thoughts?

---

From: Corey Bonnell <[email-masked]>
Date: Tue, 10 Jul 2018 12:09:22 +0000

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 the same Issuer Domain Name.

For example, the following CAA issue record:
CAA 0 issue "acmeca.com; validationmethods=http-01; accounturi=https://api.acmeca.com/acct/1"

could be expressed with two records:
CAA 0 issue "acmeca.com; validationmethods=http-01"
CAA 0 issue "acmeca.com; accounturi=https://api.acmeca.com/acct/1"

This isn't very DRY, but this would avoid interoperability conflicts with tooling and other CAs that refuse to issue certificates when encountering CAA records with invalid syntax.
 
Thanks,
Corey Bonnell
Senior Software Engineer

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

On 7/9/18, 8:57 PM, "Acme on behalf of Jacob Hoffman-Andrews" <[email-masked] on behalf of [email-masked]> wrote:

    https://scanmail.trustwave.com/?c=4062&d=9ITE2_Zkd4Asykvo5V46RlY2wgex49JVgDUDQNU2fg&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc6844%23section-3

    https://scanmail.trustwave.com/?c=4062&d=9ITE2_Zkd4Asykvo5V46RlY2wgex49JVgDVWTd4-IA&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc6844%23section-5%2e2

    https://scanmail.trustwave.com/?c=4062&d=9ITE2_Zkd4Asykvo5V46RlY2wgex49JVgGJWEd4-KQ&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2fdraft-ietf-lamps-rfc6844bis-00%23section-5%2e2

    https://scanmail.trustwave.com/?c=4062&d=9ITE2_Zkd4Asykvo5V46RlY2wgex49JVgGJSE40wKQ&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2fdraft-ietf-acme-caa-03%23appendix-A
     > http://scanmail.trustwave.com/?c=4062&d=9ITE2_Zkd4Asykvo5V46RlY2wgex49JVgDAHRt8wew&s=5&u=http%3a%2f%2fexample%2ecom IN CAA 0 issue "http://scanmail.trustwave.com/?c=4062&d=9ITE2_Zkd4Asykvo5V46RlY2wgex49JVgGRQFokzLA&s=5&u=http%3a%2f%2fexample%2enet%3b \

    

    _______________________________________________
    Acme mailing list
    [email-masked]
    https://scanmail.trustwave.com/?c=4062&d=9ITE2_Zkd4Asykvo5V46RlY2wgex49JVgGMHRNQ_Kw&s=5&u=https%3a%2f%2fwww%2eietf%2eorg%2fmailman%2flistinfo%2facme

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 10 Jul 2018 13:40:41 +0000

I prefer the RFC 6844-bis interpretation, but I note that this is not 
compliant
with the Baseline Requirements, which mandate RFC 6844.  It's not clear
what that means though since as you correctly note, RFC 6844 contradicts
itself on this point.

I would support fixing the baseline requirements along the lines of what we
did for errata 5065.

-Tim

> -----Original Message-----
> From: Acme [mailto:[email-masked]] On Behalf Of Jacob Hoffman-
> Andrews
> Sent: Monday, July 9, 2018 8:57 PM
> To: Roland Shoemaker <[email-masked]>; [email-masked]
> Cc: Hugo Landau <[email-masked]>
> Subject: Re: [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:
>
> For 6844-bis, in the LAMPS WG, we concluded that the latter was most likely 
> an
> error in the ABNF, and that semicolons were preferable:
>
>  > example.com. IN CAA 0 issue "example.net; \  >     account-
> uri=https://example.net/account/1234; \  >     validation-methods=dns-01"
>
>
> We resolved the hyphen question on the basis of interoperability: Some DNS
> UIs rejected setting CAA records with hyphens in property names, so we did
> the simple thing and removed them.
>
> I have one piece of interop data: While Route53 rejected hyphens in property
> names, it accepts semicolons separating name-value pairs.
>
> https://www.ietf.org/mailman/listinfo/acme

---

From: Hugo Landau <[email-masked]>
Date: Tue, 10 Jul 2018 17:47:40 +0100

> This isn't very DRY, but this would avoid interoperability conflicts with tooling and other CAs that refuse to issue certificates when encountering CAA records with invalid syntax.
This doesn't work; it changes logical-AND to logical-OR.

For
> CAA 0 issue "acmeca.com; validationmethods=http-01; accounturi=https://api.acmeca.com/acct/1"
the account URI AND validation method must match.

For
> CAA 0 issue "acmeca.com; accounturi=https://api.acmeca.com/acct/1"
at least one of the account URI OR validation method must match.

I support sticking with the current draft using semicolons.