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

[Corey Bonnell <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> 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
    [e-mail]
    https://scanmail.trustwave.com/?c=4062&d=9ITE2_Zkd4Asykvo5V46RlY2wgex49JVgGMHRNQ_Kw&s=5&u=https%3a%2f%2fwww%2eietf%2eorg%2fmailman%2flistinfo%2facme