ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Responsibility vs. Validity

2007-11-30 04:50:51
On Thu, 29 Nov 2007 21:36:12 -0000, Jon Callas <jon(_at_)callas(_dot_)org> 
wrote:


If the i= tag does not "mean something", and the verifier cannot
make use
of it for any purpose, then what on earth is the point of having it
in the
standard in the first place?

Who says there has to be a domain in the tag? In the example I gave,
it can be a number.

While it is an identity, we are completely open as to what that
identity has to be. It doesn't have to be an email address, or an
account, or anything. 4871 says that <string>@<domain-from-d=> is the
default, and it makes a certain sense to do that, it is not required.

It has to be of the syntactic form of an <addr>. The usual implication of such syntax appearing in a standard is that a thing that looks like an <addr> is expected to be an <addr>. If there is any other intent (e.g. it was a Message-ID), then one would expect the standard to say so. The wording in 4871 strongly suggests, by implication, that the domain at least is supposed to be a domain.

If a signer wishes to include private information in his signature to assist with his own internal processes, such as dealing with complaints, then the correct procedure is to invent his own tag for the purpose, e.g.

..............priv=1234567890...........

Thas is syntactically allowed (3.2). Granted it says "Unrecognized tags MUST be ignored", but I would regard that as applying to verifiers who have not the slightest idea what they mean. I don't think it precludes the signer from using it.

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