Re: [apps-discuss] The authentication server id, was rfc5451bis

["Murray S. Kucherawy" <[e-mail]>]

On Fri, Mar 29, 2013 at 11:33 AM, Alessandro Vesely <[e-mail]> wrote:

> >> then, a parser designed after 5451bis has to _guess_ that the one it
> >> knows is indeed "1".
> >
> > Why?  This hasn't changed in the -bis document either.
>
> In RFC 5451 it was indicated as a comment to the "version" production
> rule, as in the current draft.  That might be slightly inappropriate
> since that rule works also for the methods, which have their own
> versions.  Since -bis has a section on version tokens, readers may
> expect to find that statement there.
>

The version production is 1*DIGIT.  That's not a comment.


>
> BTW, would sender-id have had "2.0" there?
>

No.


>
> >>> I don't think this document (old or new) goes to great lengths
> >>> to establish transitive trust mechanisms, and shouldn't unless
> >>> there are implementations that do so.
> >>
> >> I agree that it shouldn't:  Section 1.2 is clear about being agnostic
> >> on the trust boundary.  However, if the local definition of "trust
> >> boundary" is such that a producer doesn't know the whole trust-list,
> >> then the MUST in the first paragraph of Section 5 is not actionable.
> >
> > Why would the producer need to know more than one entry in the list?
>
> That's usual.  Doesn't opendkim take a list of identities and compare
> each A-R against it?


Yes, when operating as a consumer of the field (for the purpose of
identifying the ones that need to be deleted), not a producer of it.


>  If it doesn't have the whole list --and admins
> may worry about allowing write access to their remardb to any possible
> downstream consumer-- then there's nothing it can do about it.
>

It doesn't need the whole list when acting as a producer.  It needs one
string.


>
> As John said, the point of the authserv-id is to allow a system to
> recognize its own A-R headers.  The "its own" part is what limits free
> extensibility of the trust boundary.
>

Consumers get to have a set that they consider "their own".  Producers can
only insert one string there, obviously.


>
> >> Renaming by prefix insertion allows recovery at very small risk, with
> >> very simple code:
> >>
> >>   dkim_header(dkim, start + dkim_unrename,
> >>      eol - start - dkim_unrename);
> >>
> >> where dkim_unrename is either 0 or the length of the prefix inserted
> >> by the upstream agent.  Note that the code above doesn't know whether
> >> the field is actually signed or not.
> >
> > You're doing this at the wrong layer.  This change would cause the DKIM
> > validation code to see something different.
>
> Different from what the rest of the system sees, but hopefully not
> different from what the signer signed.
>

Of course it is.  What you're feeding to dkim_header(), by changing it,
will invalidate the signature, if that field was signed.


> > You need to send the instruction in the other direction, which makes
> > it more complicated.
>
> What do you mean?  I cannot tell the sender that I don't trust it, so
> it should stop cluttering messages with its A-Rs.  An A-R for the auth
> method, for example, can only be written there.
>
> OTOH, it is possible to recognize that a sender/signer is trusted and
> unrename its A-Rs after verification too, when changes are committed
> to disk.  I'm not going to code such complication, for the time being.
>

I'm totally confused by what you're getting at here.

dkim_header() tells the DKIM layer what it's signing or verifying.  Why you
would want to change that is beyond me.  What you're trying to do is alter
the name of the field so consumers won't see it.  dkim_header() is
absolutely the wrong way to do that.  Rather, you need to tell the MTA to
do the rename operation, which might actually be a delete+insert
operation.  DKIM has absolutely nothing to do with that.

-MSK