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" <acme-boun...@ietf.org on behalf of j...@eff.org> wrote: There's a similar issue for parameters: RFC 6844 section 3 says each name-value pair is separated by a semicolon: https://scanmail.trustwave.com/?c=4062&d=9ITE2_Zkd4Asykvo5V46RlY2wgex49JVgDUDQNU2fg&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc6844%23section-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://scanmail.trustwave.com/?c=4062&d=9ITE2_Zkd4Asykvo5V46RlY2wgex49JVgDVWTd4-IA&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc6844%23section-5%2e2 > 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://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 > parameters = (parameter *WSP ";" *WSP parameters) / parameter ACME-CAA's examples use semicolons: 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 \ > 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? _______________________________________________ Acme mailing list Acme@ietf.org https://scanmail.trustwave.com/?c=4062&d=9ITE2_Zkd4Asykvo5V46RlY2wgex49JVgGMHRNQ_Kw&s=5&u=https%3a%2f%2fwww%2eietf%2eorg%2fmailman%2flistinfo%2facme _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
