Re: [apps-discuss] draft-kucherawy-rfc5451bis

[Dave Cridland <[e-mail]>]

On Thu, Mar 14, 2013 at 7:40 PM, Murray S. Kucherawy <[e-mail]>wrote:

> I've uploaded an update to draft-kucherawy-rfc5451bis for review.  It
> incorporates the feedback I've received over the last few months since the
> last version.
>
> https://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis/
>
>
I've not seen this document before, nor its predecessor, so I'm casting a
fresh pair of eyes on it. This may result in my not having understood the
draft, but I'll pretend that's the draft's fault rather than it possibly
being my own idiocy.

For the most part, this document looks fine and solid.

Two items concern me in a major way; one further item has me mildly nervous.

First, the minor one:

The header includes definition of a version ABNF production optionally
following the authentication server's identity. It took me some time to
find the note of how to treat this; I didn't see any examples with it
present either.

Second, the first major one:

The examples tend to imply, for the most part, a canonical form to the
header, which places CFWS is only particular places. In particular, all the
examples are of the form auth-srv-id "; " method "=" result, with some
optional properties and/or reason, with one single exception (which
includes a comment in lieu of a reason). It's not immediately apparent to a
comparatively novice reader that the following header field is valid:

Authentication-Results: foo.example.net (My mailserver) / (I am number) 1
(You see) ; dkim (Because I like it) /2 (Two yay) = (wait for it) pass ;
policy (And a dot can go here) . (Like that) fruit (which surprised me) =
(because I was not expecting it) banana

I appreciate it's always nicer to only write pretty examples, but given the
specification, providing a nasty one is probably needed, lest people expect
to take a whitespace delimited token and split it on '='. For some reason I
particularly wasn't expecting the CFWS around the dot. (Maybe that's
because I'm out of practise with header parsing).

In any case, highlighting this with an example seems appropriate and useful.

Thirdly, one more major concern:

You'll note that I included a version for the method in my example above.
The definition for this, from the comments in the ABNF, suggests that this
relates to the version of RFC 5451 and successors used, but this seems
unlikely - I'm also at a loss as to what a receiving implementation should
do with such a method, since the handling of version seems to be specified
only for the version number after the auth-srv-id.

I have a vague suspicion that the correct thing to do here may be to
deprecate the method version entirely, but I might be missing something -
still, it doesn't appear to relate to the method, but the header field.

Dave.