Hi Ilari, You're correct about the ambiguity in 6844-bis regarding whitespace handling in the issuevalue production rule. I sent a message to LAMPS (https://www.ietf.org/mail-archive/web/spasm/current/msg01466.html) to get this corrected in 6844-bis, referencing your email.
Thanks, Corey On 7/18/18, 10:29 AM, "Acme on behalf of Ilari Liusvaara" <[email protected] on behalf of [email protected]> wrote: On Wed, Jul 18, 2018 at 01:17:26PM +0000, Salz, Rich wrote: > > Would you be willing and able to write, or co-write, a 6844 errata > that corrected that document so that the current ACME CAA draft was > compliant? At the WG meeting yesterday, we got feedback that this > would be acceptable to the Area Director, and everyone agrees it > is a much better solution than waiting for the 6844bis document to > become an RFC. In my opinion, there is significant difference between: - Fixing the ambiguous behavior in RFC6844 grammar in a way that does not change the language (which means the set of strings that are valid in grammar) but fixes the ambiguous cases. - Changing the RFC6844 language to make it parse the examples from ACME-CAA as the draft intends them to be parsed. Even if this grammar would match the examples from the document. As reminded by recent change from validation-methods to validationmethods, there apparently are DNS provoders that do check what is entered against the language. The no-change-to-language fixed grammar changes would look something like (omitting unchanged symbols 'domain', 'parameter' and 'space' and any symbols transitively used by those three): issuevalue = space [domain space] [";" space [parameters space]] parameters = parameter *(mspace parameter) mspace = 1*(SP / HTAB) (Hope I got that right) But this does not parse the examples from ACME-CAA correctly. For example: issue "http://scanmail.trustwave.com/?c=4062&d=vM7P2-IdIAR0aSvyVFMWRv8J93MJNR3h5pH_j3xvMw&s=5&u=http%3a%2f%2fexample%2enet%3b accounturi=https://example.net/account/1234; validationmethods=dns-01" would parse as: space: "" domain: "http://scanmail.trustwave.com/?c=4062&d=vM7P2-IdIAR0aSvyVFMWRv8J93MJNR3h5s2t1CttZA&s=5&u=http%3a%2f%2fexample%2enet"; space: "" space: "" parameters: parameter: tag: "accounturi" value: "https://scanmail.trustwave.com/?c=4062&d=vM7P2-IdIAR0aSvyVFMWRv8J93MJNR3h5sP91CtsPg&s=5&u=https%3a%2f%2fexample%2enet%2faccount%2f1234%3b"; mspace: " " parameter: tag: "validationmethods" value: "dns-01" space: "" Note the trailing ';' in the account URI. Notes about the construction: - The reason why the space symbols are inside optional blocks is to avoid two back-to-back space symbols, as that would allow ambiguous parse of some strings. - I introduced mspace symbol (short from "mandatory space") to stand for at least one space in order to separate parameters.. I also found a minor issue with the RFC6844bis grammar: It has possibility of having two back-to-back *WSP symbols that can compete with each other. One possible fix would be: issuevalue = *WSP [domain *WSP] [";" *WSP [parameters *WSP]] Which ensures there is always a non-empty symbol (domain or parameters, neither of which can be empty and neither of which can start or end with WSP) between two *WSP sybmbols. -Ilari _______________________________________________ Acme mailing list [email protected] https://scanmail.trustwave.com/?c=4062&d=vM7P2-IdIAR0aSvyVFMWRv8J93MJNR3h5pao3SFjNA&s=5&u=https%3a%2f%2fwww%2eietf%2eorg%2fmailman%2flistinfo%2facme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
