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

[Eric Allman]

Well, this is unfortunate, and I'm not sure how we ended up with both 
FWS and LWSP at the same time.  As Frank noted they are nearly 
equivalent.

The problem is that both of them are assuming use in a header field 
context, which requires the trailing white space.  Contrary to what 
Frank says, just replacing LWSP with [FWS] won't solve the problem. 
In fact, since base64string is used both in the DKIM-Signature header 
field and in the selector record, we would need to split that in two. 
Ugly.

For the time being I agree with Paul's suggestion: live with it. 
This is the sort of thing that can be solved in DKIMbis, which I'm 
sure will be required before DKIM gets to full standard.

eric


--On March 7, 2007 9:34:45 AM +0100 Mark Martinec 
<Mark.Martinec+dkim at ijs.si> wrote:

> I came across a real life example where a public key as returned
> by a DNS record contained embedded CR LF, probably due to a
> misconfiguration or a broken DNS server implementation.
>
> Two different DKIM implementations gave different treatment to the
> situation, one claiming 'key syntax error', the other accepted it.
>
> Turning to draft-ietf-dkim-base-10 reveals:
>
>    key-p-tag    = %x70 [FWS] "=" [ [FWS] base64string ]
>    base64string = 1*(ALPHA / DIGIT / "+" / "/" / LWSP)
>                   [ "=" LWSP [ "=" LWSP ] ]
>    LWSP =  *(WSP / CRLF WSP)
>
> which would indicate that a public key in TXT RR
> like the following would be alright:
>
>   k=rsa; p=MIGfMA0GCSq<CR><LF><SP>GSIb3DQEBAQUA...
>
> while the one without a <SP> would not be syntactically correct:
>
>   k=rsa; p=MIGfMA0GCSq<CR><LF>GSIb3DQEBAQUA...
>
> It seems the requirement to insist on LWSP (e.g. a WSP must follow
> CRLF) in a non- message header context is very much artificial and
> unwarranted.
>
>   Mark
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>