ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] LWSP in base64-encoded public key TXT RR

2007-03-09 09:46:53
On Thu, 08 Mar 2007 19:07:35 -0000, Eric Allman <eric+dkim(_at_)sendmail(_dot_)org> wrote:

I'm thinking of the following addition to the p= description in 3.6.1:

INFORMATIVE NOTE: A base64string is permitted to include white space (LWSP) at arbitrary places; however, any CRLFs must be followed by at least one WSP character. Implementors and administrators are cautioned to ensure that selector TXT records conform to this specification.


But that is fixing the WRONG problem.

Our Base document defines a new DKIM-Signature header field which is intended to appear in Emails. This header field contains a list of <tag-value>s, and one of those defined (and indeed REQUIRED) in this heasder field is the <sig-b-tag>, which in turn contains a <base64string>, which in turn can contain an arbitrarily long sequence of <LWSP>s each of which in turn can contain an arbitrarily long sequence of the form *(CRLF WSP).

BUT it is expressly forbidden for an RFC 2822 object to be generated containing such a sequence in its <header> (though, for liberality and due to the presence of <obs-FWS> such a sequence is to be accepted).

Therefore, our Base document is *inconsistent* with RFC 2822, and therefore this misfeature is most certainly a BUG.

I cannot imagine that the IETF procedures prohibit the fixing of what are clear bugs at any time up to the point of publication of the RFC (and, after that, an RFC-erratum is the proper mechanism).

In this case, the proper fix would appear to be

   base64string =     bvalchar 0*( [ FWS ] bvalchar ) 0*2( [FWS] "=" )
   bvalchar     =     ALPHA / DIGIT / "+" / "/"

And if you look closer, <tag-value> itself, currentloy defined as

        tag-value =  [ tval 0*( 1*(WSP / FWS) tval ) ]

exhibits the same problem, and should have been

        tag-value =  [ tval 0*( FWS tval ) ]

[Recall that:
   LWSP =  *(WSP / CRLF WSP)
   FWS =   [*WSP CRLF] 1*WSP
]

Those new definitions will certainly keep RFC 2822 happy. Whether the revised <base64string> is too restrictive for selector TXT records is another matter, though I doubt we really want them to contain long sequences of *(CRLF WSP).

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html