ietf-mailsig
[Top] [All Lists]

Re: The cost of choices

2005-07-26 21:47:26


On Tue, 26 Jul 2005, Dave Crocker wrote:

The usual IETF model is to define a core capability that has the minimum
functionality to do something useful.  Everyone claiming to write code that
"supports" the specification MUST implement all of that functionality.

There is a difference in supporting functionality in the code and using
functionality as requirement for every protocol transaction. You appear to imply its the same thing.

Not only that but even that core requirement can change (from MUST to SHOULD and back), let me quite you from RFC3851:

-------
 1.5.  Changes Since S/MIME v3

   The RSA public key algorithm was changed to a MUST implement key
   wrapping algorithm, and the Diffie-Hellman algorithm changed to a
   SHOULD implement.

   The AES symmetric encryption algorithm has been included as a SHOULD
   implement.
------

Does the above imply that every S/MIME message is using RSA public
key? Not it does not (it does imply that, for greatest compatiblity
it should, but they signer may also choose to use Diffier-Hellman
or AES if its fine for their needs).

It is absolutly appropraite to have sender let it be known what
algorithm they choose and it may also be approprate for recipient
to communicate their prference (many if not most emails are going
to known recipient systems and mail client may well be able to
keep track or find these preferences "on the fly").

As such I completely agree with Phillip that policy record needs
to be expanded to make it possible for sender to provide information
about wich protocol is supported. If we don't have that and we
continue to insist that dns txt is a must for everyone to publish,
then why are you even bothering adding "q" in the tag.

My general sense is that DKIM suffers from all the same problems as domainkeys (but not IIM) as far as that it it makes upgrading the protocol and adding new features on deployed architecture close to impossible (except by introducing totally new header field or possibly new version which if you read the draft basicly would be interpreted the same).

BTW - About the version, you should specify what happens if the
sender reports in policy that it supports DKIM and the mail signature
has DKIM field with version unknown to verifying agent. How should
the agent deal with such policy - as if no DKIM field was present?

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net

<Prev in Thread] Current Thread [Next in Thread>