On Mon, Jul 16, 2018 at 08:08:24PM -0700, Roland Shoemaker wrote: > I know this is quite late but could we reserve some time for a > discussion of the (possible) pending issues with regard to the > parameter format mismatch between ACME-CAA and 6844 and possible > solutions.
I took a look at the issue: The RFC 6844 grammar is ambiguous due to incorrect multiplicities. As far as I can see, there is no erratum for this. As an example, consider the multiple-parameter example from the ACME-CAA document: issue "example.net; accounturi=https://example.net/account/2345; validationmethods=http-01" This has unique valid meanings for both RFC6844 and RFC6844bis grammars, but the two are different! Even taking additional constraint that accounturi value is an uri is no help. Now, under RFC6844bis rules, one can presumably rewrite this rule into: issue "example.net;accounturi=https://example.net/account/2345;validationmethods=http-01"; The RFC6844bis parse is still the same, but now there are 18(!) possible meanings under RFC6844 rules. One of those is the same as the above. However, what I think is the most sensible way to fix the RFC6844 grammar gives different meaning from the first example (this can not alter the first example, because there the meaning is unique already). And restriction to URI does not help here either. Another rewrite under RFC6844bis rules would be: issue "example.net;accounturi=https://example.net/account/2345 ; validationmethods=http-01" RFC6844bis parse is still the same, but RFC6844 rules would reject this as invalid. RFC6844 and RFC6844bis grammars have all of: - Strings that are valid in RFC6844 but not RFC6844bis. - Strings that are valid in RFC6844bis but not RFC6844. - Strings that have unique different meanings for RFC6844 and RFC6844bis. - Strings that have unque meaning in RFC6844bis, but multiple meanings in RFC6844, all different from the unique meaning in RFC6844bis. If one fixes the RFC6844 grammar in most obvious way (by disallowing zero space between parameters, which is the source of ambiguous cases), then: - Strings that are valid in RFC6844(fixed) but not RFC6844bis. - Strings that are valid in RFC6844bis but not RFC6844(fixed). - Strings that have unique different meanings for RFC6844(fixed) and RFC6844bis. Since the language is not changed by the fix, the last two cases with unfixed RFC6844 are collapsed into the last case. -Ilari _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
