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 "example.net; accounturi=https://example.net/account/1234; validationmethods=dns-01" would parse as: space: "" domain: "example.net" space: "" space: "" parameters: parameter: tag: "accounturi" value: "https://example.net/account/1234;"; 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://www.ietf.org/mailman/listinfo/acme
