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

Reply via email to