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

From: Mark Martinec <[email-masked]>
Date: Wed, 7 Mar 2007 09:34:45 +0100

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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 07 Mar 2007 12:34:20 +0100

Mark Martinec wrote:

> a public key in TXT RR like the following would be alright:

> 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.

The ABNF also uses [FWS] with a very similar effect.  The main
difference between [FWS] and LWSP is that the latter allows
"folded" lines consisting only of trailing white space:

"A" [FWS] "B" allows AB, A<WSP>B, A<CRLF><WSP>B, etc.  But you
would need <obs-FWS> to match any A<CRLF><WSP><CRLF><WSP>B

"A" LWSP "B" has this ugly <obs-FWS> feature.  It's a clear
MUST NOT for RFC 2822 generators.  The DKIM base RFC uses a
clean <FWS> without <obs-FWS>, see (2.3)

But it also uses the 4234 <LWSP> in (2.4), sigh.  It's IMO a
bit late to address your concern, but maybe Eric could still
do a s/LWSP/[FWS]/g in AUTH48 eliminating LWSP everywhere (?)

Frank

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Mar 2007 08:53:16 -0800

>do a s/LWSP/[FWS]/g in AUTH48 eliminating LWSP everywhere (?)

Absolutely not. This is a technical change. If we tried that, the 
document would have to go through IESG review again.

--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 07 Mar 2007 19:09:19 +0100

Paul Hoffman wrote:

>> maybe Eric could still do a s/LWSP/[FWS]/g in AUTH48
>> eliminating LWSP everywhere (?)
 
> Absolutely not. This is a technical change.

It's IMO more in the direction of an erratum.  Nobody
could claim with a straight face that they need lines
consisting only of white space for their folding magic.

> If we tried that, the document would have to go through
> IESG review again.

I thought that this depends on the AD or the shepherd (?)
Of course I don't want a new IESG review or other delays.

Frank

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Mar 2007 11:41:19 -0800

>consisting only of white space for their folding magic.

Even if true, it is still a technical change. dkim-base is a standard 
*today*, even before the RFC is issued. Implementations of *the 
standard* have already been deployed. You are proposing a change to 
the way an implementation needs to act.

>I thought that this depends on the AD or the shepherd (?)

It is up to the RFC Editor.

>Of course I don't want a new IESG review or other delays.

Fully agree.

--Paul Hoffman, Director

---

From: Eric Allman <[email-masked]>
Date: Wed, 07 Mar 2007 16:04:13 -0800

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 
<[email-masked]> wrote:

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 Mar 2007 01:10:36 +0000

Say if you had to write an erratum explaining this, rather than
fixing it...what'd you say?

And (assuming such a note is useful) would it make sense to
add that to the RFC?

S.

Eric Allman wrote:
> FWS and LWSP at the same time.  As Frank noted they are nearly equivalent.
> 
> 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
> 
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Mar 2007 17:53:41 -0800

>fixing it...what'd you say?

An erratum sounds like a fix. Instead, I hope you mean "an 
explanation of what is in the spec, even if it wasn't what we wanted".

>And (assuming such a note is useful) would it make sense to

That can be added to the RFC, if done carefully. It would be even 
better if it was done and agreed to on the WG mailing list, so that 
the responsible AD can tell the RFC Editor "this has already been 
agreed to by the WG" and let the RFC Editor decide whether or not it 
is editorial or a technical change.

--Paul Hoffman, Director

---

From: Eric Allman <[email-masked]>
Date: Wed, 07 Mar 2007 19:12:34 -0800

Paul, I'm not clear what you are suggesting.  Is this some sort of 
addendum to the spec that says "the ABNF says X, but we really 
intended Y, so consider it to be that way"?  If we do that it seems 
like we have really changed the spec.

Or are we saying "the ABNF says X, but we really intended Y, but it's 
too late to fix this and you should make a note of it"?  Essentially, 
this would be a warning guide to people creating selectors.  That 
does not change the spec, and could be done with an informative note.

eric

--On March 7, 2007 5:53:41 PM -0800 Paul Hoffman 
<[email-masked]> wrote:

> agreed to by the WG" and let the RFC Editor decide whether or not
> it is editorial or a technical change.
>
> --Paul Hoffman, Director

---

From: Mark Delany <[email-masked]>
Date: Wed, 07 Mar 2007 20:10:41 -0800

> standard* have already been deployed. You are proposing a change to the 
> way an implementation needs to act.

This argument has been brought up at nearly every change made. If 
pre-standard compatibility is so important then DK signatures would 
still be valid. They aren't. So would IIM signatures. They aren't. So 
would early DKIM signatures. They aren't.

Current DKIM deployment is infinitesimal compared to DK, so I find the 
"already deployed" argument bogus in the extreme.

Besides, as I understand it, most implementations will serendipitously 
work anyway as the presence of WS in Selectors is uncommon.

>> Of course I don't want a new IESG review or other delays.

Why not? What's the rush? DKIM has been alive for at least a year and DK 
has been alive for at least two years? I don't understand why a small 
delay to get something right is considered so negatively by a technical 
standards group.

Mark.

---

From: Hector Santos <[email-masked]>
Date: Wed, 07 Mar 2007 23:56:39 -0500

> "already deployed" argument bogus in the extreme.

+1, thank you.

> delay to get something right is considered so negatively by a technical 

+1, thank you.

--
HLS

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 Mar 2007 10:05:02 +0000

Paul Hoffman wrote:
> An erratum sounds like a fix. 

No. It seems like this isn't a trivial thing to fix, so such
a change shouldn't be attempted in AUTH48. ('Course that hasn't
stopped people before;-)

 > Instead, I hope you mean "an explanation
> of what is in the spec, even if it wasn't what we wanted".

Yes.

> That can be added to the RFC, if done carefully. It would be even better 
> if it was done and agreed to on the WG mailing list, so that the 
> responsible AD can tell the RFC Editor "this has already been agreed to 
> by the WG" and let the RFC Editor decide whether or not it is editorial 
> or a technical change.

Of course.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 Mar 2007 10:02:12 +0000

Mark Delany wrote:
> has been alive for at least two years? 

We each only have so many cycles to devote to this document. I
strongly believe the WG don't want to reset the process and are
right to hold that opinion.

Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 Mar 2007 10:08:13 +0000

Eric Allman wrote:
> this would be a warning guide to people creating selectors.  That does 
> not change the spec, and could be done with an informative note.

That's what I thought might be useful enough to try.

Wanna try draft a paragraph? Maybe it'll start with something like:

"Deployment experience since this specification was agreed has
shown that..."

If we have such a paragraph agreed then we can think about whether
to include it or not. If not, then at least its on the list and we
can add it to the errata page for the RFC.

S.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 08 Mar 2007 07:17:24 -0800

> required before DKIM gets to full standard.

This seems like a perfect reason why Postel's Rule still applies:
putting whitespace in a base64 string is just asking for trouble
in the key record, but a good receiver should be tolerant regardless
of the letter of the spec since it doesn't change the underlying
semantics.

As Eric alludes to, this is exactly why there's PS --> DS to clean
these kinds of niggling things up; if this is the only ABNF goof,
we'd be doing pretty well.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Mar 2007 07:40:57 -0800

> required before DKIM gets to full standard.

I'll suggest something even stronger:

Strictly speaking, this is not a bug, so "fixing" it is not the issue.

Why is is not a bug?  Well, while we might now wish we had specified things a 
bit differently, the specification in its current form works and it does not 
impose undue burdens on implementors or operators.  So the nature of what is 
there, that we might wish were different, falls into the realm of preference 
or taste.

Hence, the way to "fix" the incompatibility being found in the field is to 
change the implementation, not the specification.

As Paul notes, although documenting this issue might be useful, it is not 
"erratum". (And, Eric, that is quite different from either of the alternatives 
you had, in responding to Paul.)  The documentation should not declare what 
was intended, but merely highlight something that exists and that we have some 
basis for knowing is worth flagging because it appears to be easy to 
misinterpret.

Stephen's suggested opening text for the note about this strikes me as exactly 
the right perspective.  Here is what is, rather than here is what we wish, or 
here is a bug in the spec, or any such thing.

A small change from Stephen's text that I would suggest is to not refer to 
"since the spec was completed or approved" but merely to state a clarification 
of what is in the spec.

So, wherever this gets documented, it should say something like:

      "NOTE:  The specification permits folded white space (FWS) in the DKIM 
DNS TXT record.  FWS requires that a <CR><LF> be followed by at least one 
linear white space (LWSP) character.  Implementors and administrators are 
cautioned to be careful to ensure that the TXT records produced conform to the 
specification."

Yes, we might later choose to "enhance" the specification, to allow the case 
that has appeared in the field, but then, we might not.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Mar 2007 08:16:45 -0800

At 7:12 PM -0800 3/7/07, Eric Allman wrote:
>intended Y, so consider it to be that way"?

Definitely not. I don't think that is what Stephen was saying either.

>If we do that it seems like we have really changed the spec.

Right.

>Or are we saying "the ABNF says X, but we really intended Y, but 
>it's too late to fix this and you should make a note of it"? 
>Essentially, this would be a warning guide to people creating 
>selectors.  That does not change the spec, and could be done with an 
>informative note.

Exactly right. "You might make your selectors wrong if you don't 
notice this detail of the spec."

--Paul Hoffman, Director

---

From: Jim Fenton <[email-masked]>
Date: Thu, 08 Mar 2007 09:27:12 -0800

> misconfiguration or a broken DNS server implementation.

I think the key phrase here is "probably due to a misconfiguration or a 
broken DNS server implementation."  While it doesn't seem that there's a 
good reason to require SP after CRLF in the key record, I also can't 
think of a good reason why the DNS server needs to split it in the first 
place.  If this behavior had been a characteristic of a common DNS 
server implementation, I think we would have seen it before now.

I don't think a change to the spec is required just because there's a 
name server that 's broken, misconfigured, or otherwise did something 
unexpected.

-Jim

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 08 Mar 2007 19:06:01 +0100

Michael Thomas wrote:

> if this is the only ABNF goof we'd be doing pretty well.

Yes.  And actually I didn't claim that my proposed fix
addresses the problem of the OP.  I only don't like lines 
containing only trailing white (no visible character), if
their semantics differs from empty lines:

It's too easy to lose all trailing white space with a text
editor.  [FWS] avoids this potential trap, LWSP doesn't.

Of course that's more important in RFCs like 2822, USEFOR,
or maybe 2831bis, for DKIM it's less relevant.  Ignoring
folks using a text editor to create their records, _and_
trying to add "apparently empty" lines for obscure reasons.

Frank

---

From: Eric Allman <[email-masked]>
Date: Thu, 08 Mar 2007 11:07:35 -0800

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.

eric

---

From: Michael Thomas <[email-masked]>
Date: Thu, 08 Mar 2007 11:21:20 -0800

Eric Allman wrote:
> least one WSP character.  Implementors and administrators are cautioned 
> to ensure that selector TXT records conform to this specification.

Not to be too jaded, but does anybody think this will have any practical
effect whatsoever? I would lay long odds that whoever put that key into
their DNS didn't read the DKIM spec -- or at least read it with kind of
critical eye.

What would actually be better here, IMO, is to find out _how_ this
happened. That is, is this a pathological case for a DNS server we
ought to care about. If this just a random one off misconfiguration,
I'm not sure what the point is for introducing more text with its
inherent potential of itself being misconstrued...

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Mar 2007 11:27:54 -0800

> to ensure that selector TXT records conform to this specification.

+1

d/
-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 8 Mar 2007 14:31:41 -0500

> cautioned to ensure that selector TXT records conform to this
To the extent I understand the issue, I think this makes sense, but I don't 
see value added in the last sentence since the whole point of the spec is to 
be able to conform to it.  I'd suggest deleting the last sentence.

Scott K

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 Mar 2007 19:36:01 +0000

Works for me,
S.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Mar 2007 11:36:40 -0800

Michael Thomas wrote:
> effect whatsoever? 

1. It shows legitimate due diligence.  A real-world encounter suggests an 
operational problem and this note attends to it.

2. It dispatches the issue from the near-term IETF agenda, thereby relieving 
the working group from a hassle.

I tend to view both of these as practical effects.  (And, yeah, I suspect I 
know the sort of thing you actually had in mind and no, I don't think this 
will deal with it.)

> happened. 

And my point #2, above, is exactly why I suggest it would *not* be better.

It is not the job of this wg to diagnose misbehaviors by s/w or operators. 
That's better done elsewhere, like

    dkim-dev <http://mipassoc.org/mailman/listinfo/dkim-dev> or

    dkim-ops <http://mipassoc.org/mailman/listinfo/dkim-ops>.

d/

-- 

   Dave Crocker

---

From: Eric Allman <[email-masked]>
Date: Thu, 08 Mar 2007 11:41:40 -0800

Mike,

I agree we can't force people to read the spec.  But given that many 
of us read the spec and didn't notice this point, I think it's worth 
highlighting for those who do actually read it.

eric

---

From: Eric Allman <[email-masked]>
Date: Thu, 08 Mar 2007 11:43:33 -0800

I didn't include the last sentence at first, but it looked so ... 
naked.  On the other hand, it does sort of say "people reading this 
spec should actually read it," which is indeed rather silly.

I can go either way on it.

eric

--On March 8, 2007 2:31:41 PM -0500 Scott Kitterman 
<[email-masked]> wrote:

>> 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.
>>
>> eric
> To the extent I understand the issue, I think this makes sense, but
> I don't  see value added in the last sentence since the whole point
> of the spec is to  be able to conform to it.  I'd suggest deleting
> the last sentence.
>
> Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Mar 2007 11:50:34 -0800

I actually believe the last sentence is important.  The first sentence is a 
warning about a generic construct.  The second directs the reader to a 
particular context -- which we already know can cause problems -- in which 
that construct occurs.

d/

Eric Allman wrote:
> naked.  On the other hand, it does sort of say "people reading this spec 
> should actually read it," which is indeed rather silly.
> 

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Thu, 08 Mar 2007 12:04:42 -0800

Dave Crocker wrote:
> 1. It shows legitimate due diligence.  A real-world encounter suggests 
> an operational problem and this note attends to it.
> 
> 2. It dispatches the issue from the near-term IETF agenda, thereby 
> relieving the working group from a hassle.

Which is to say that it will have no practical effect whatsoever.

> 
> I tend to view both of these as practical effects.  (And, yeah, I 
> suspect I know the sort of thing you actually had in mind and no, I 
> don't think this will deal with it.)
>

Practical from a process CYA maybe, but not in the real world of
interoperability.

> It is not the job of this wg to diagnose misbehaviors by s/w or 
> operators. That's better done elsewhere, like

No. Sorry. If we're only interested in process CYA this is a fine way
to do that. I'm a lot more interested in whether the spec will
interoperate though. Going into ostrich mode to run out the clock is
only good when you luck out and it really was an outlier. And if we're
depending on luck, what's currently in draft is as good as anything.

		Mike

---

From: Hector Santos <[email-masked]>
Date: Thu, 08 Mar 2007 15:09:47 -0500

+1.

This is good enough for passing the "SPEC" buck. :-)

--
HLS

---

From: Hector Santos <[email-masked]>
Date: Thu, 08 Mar 2007 15:31:25 -0500

> Which is to say that it will have no practical effect whatsoever.

Hmmm, so the OP meant nothing? Did that not happen?  Don't you think it 
can happen more?

--
HLS

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 8 Mar 2007 14:38:38 -0800

I do not see where making the change in the spec is going to reduce compatibility.

On the contrary I think that if we don't change the spec to say what we meant we will see more incompatibility.

The whole point of Proposed vs Draft is to catch this type of thing. We don't have a standard yet. Its an errata on a proposed standard. It happens.

If someone has an implementation that has a problem with this that would be another issue entirely.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 8 Mar 2007 15:16:16 -0800

How about

"Implementers should note that the ABNF speficied above is in error and may be changed in future protocol versions. Implementations should accept key records compliant with the following syntax:"

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Thursday, March 08, 2007 5:08 AM
> To: Eric Allman
> Cc: ietf-dkim; Paul Hoffman
> Subject: Re: [ietf-dkim] LWSP in base64-encoded public key TXT RR
> 
> 
> 
> Eric Allman wrote:
> "Deployment experience since this specification was agreed 
> has shown that..."
> 
> If we have such a paragraph agreed then we can think about 
> whether to include it or not. If not, then at least its on 
> the list and we can add it to the errata page for the RFC.
> 
> S.

---

From: Mark Martinec <[email-masked]>
Date: Fri, 9 Mar 2007 01:24:14 +0100

> inherent potential of itself being misconstrued...

For the curious:
  s1024._domainkey.123greetings.com
(they are probably unaware of the issue)

>From the DKIM implementor's point of view, a relevant question is:
should a verifier be liberal and accept the key, or must it be rejected
as syntactically invalid.

  Mark

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Mar 2007 17:42:19 -0800

At 2:38 PM -0800 3/8/07, Hallam-Baker, Phillip wrote:
>On the contrary I think that if we don't change the spec to say what 
>we meant we will see more incompatibility.

Or we can change the spec to make it clearer what the spec says.

>The whole point of Proposed vs Draft is to catch this type of thing.

Bosh: that isn't even part of the point. Changing the 
bits-on-the-wire interpretation is only done when advancing a 
standard except when some huge mistake has been made.

>We don't have a standard yet.

Bosh again. See 
<http://mipassoc.org/pipermail/ietf-dkim/2007q1/007026.html>. It is a 
standard *today*.

>  Its an errata on a proposed standard. It happens.

It happens sometimes, but only in extreme cases; this isn't one of those.

>would be another issue entirely.

The first message on this thread was an example of that.

At 3:16 PM -0800 3/8/07, Hallam-Baker, Phillip wrote:
>How about
>
>"Implementers should note that the ABNF speficied above is in error 
>and may be changed in future protocol versions. Implementations 
>should accept key records compliant with the following syntax:"

Absolutely not. What a great way to make people not want to implement the spec.

--Paul Hoffman, Director

---

From: Mark Martinec <[email-masked]>
Date: Fri, 9 Mar 2007 15:36:36 +0100

> > ought to care about.

A bit of experimenting with BIND and reading the zone file syntax
in rfc1035 can explain what probably happened. All entries below are
syntactically correct as far as the zone syntax and DNS is concerned.

right._domainkey  TXT  ("k=rsa; p=MIG"
                        "MAG0udE82Yzb7"
                        "xLv4QnQIDAQAB")

wrong._domainkey  TXT   "k=rsa; p=MIG\
MAG0udE82Yzb7\
xLv4QnQIDAQAB"

wrong2._domainkey TXT  "k=rsa; p=MIG\013\010MAG0udE82Yzb7xLv4QnQIDAQAB"

  Mark

---

From: Michael Thomas <[email-masked]>
Date: Fri, 09 Mar 2007 06:55:13 -0800

> wrong2._domainkey TXT  "k=rsa; p=MIG\013\010MAG0udE82Yzb7xLv4QnQIDAQAB"

This is actually why I thought this might be useful: if we're going to
give any informative advice about this at all, it would be useful to
couch it in terms of potential gotchas since the key sizes are long.
Just warning that the ABNF is a holdover from the signature header
doesn't give any motivation of why somebody would care about this.

		Mike

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 09 Mar 2007 16:43:34 -0000

> 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: [email-masked]      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

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 10 Mar 2007 16:51:20 +0100

> But that is fixing the WRONG problem.

Probably my fault, because I found a second problem (LWSP in general)
while talking about the first problem (FWS in DNS TXT records).  The
OP actually meant [FWS] (not only the worse LWSP) in DNS TXT records,
and Eric's proposal fixed that.

For my LWSP vs. [FWS] proposal I said that it's "in the direction of
an erratum", because I also only considered the DNS TXT records.

But now you found that LWSP is really used in a header field, and as
you say that violates a MUST NOT in 2822.  That definitely _is_ an
erratum, and it has to be fixed a.s.a.p. by replacing LWSP by [FWS].

Error as in "wrong", not error as in "editorial preference", or error
as in "technical change needing a new IESG review."  It has to be
fixed and it doesn't need a new review - unless persons claiming that
it needs a new IESG review produce the 2822bis supporting this claim.

A minimal fix would be a "MUST NOT generate" in prose reflecting the
"MUST accept <obs-FWS>" in 2822.

> therefore this misfeature is most certainly a BUG.

ACK.  We have the advantage of some years of discussions in USEFOR
about related 2822 side effects... :-)  And we certainly made sure
to kill all header lines containing only of trailing white space.

It would completely garble a "resent" email if it's edited with a
text editor removing trailing white space:  The mail header with a
<some><CRLF>1*<WSP><CRLF>1*<WSP><thing> would then result in
<some><CRLF><CRLF>1*<WSP><thing>, with the <thing> as start of the
body.  Unacceptable.

> 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).

+1

>     bvalchar     =     ALPHA / DIGIT / "+" / "/"

+1.  Removing discussions of "LWSP" in the prose, or replacing them
by "[FWS]" or "optional FWS".  DKIM like USEFOR already has a clean
no nonsense version of <FWS>, unlike RFC 2822 with its <obs-FWS>.

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

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

ACK.  Well, nobody promised that AUTH48 is always boring.  And there
are clear MUST NOTs in 2822 justifying these fixes.  Keeping it as is
is no option, a violation of 2822 in Sender ID was already appealed
(succesfully).

> 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).

+1

Frank