Yes, the RFC 6844 grammar is a mess, and it has significantly impeded efforts to improve CAA. It's one of the things I think is most important to fix in 6844bis.
It is particularly troubling because CABF rules point to 6844, and some people have been sticklers about requiring very strict compliance with RFCs that are pointed to by the BRs. For 6844, it's often very unclear what's compliant, as the document is often ambiguous, and contradicts itself and other well-known RFCs! I'm a big fan of CAA (as long as it isn't used anti-competitively ...), but 6844 has been an endless source of headaches. High quality analysis like Ilari's will go a long way towards helping us make 6844bis much better... -Tim > -----Original Message----- > From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Ilari Liusvaara > Sent: Tuesday, July 17, 2018 3:05 AM > To: Roland Shoemaker <rol...@letsencrypt.org> > Cc: Salz, Rich <rs...@akamai.com>; acme@ietf.org > Subject: [Acme] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for > ACME-CAA discussion at 102) > > 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;validationmetho > ds=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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
