ietf-mxcomp
[Top] [All Lists]

Re: Drive Towards Consensus

2004-06-21 20:32:25

In 
<C6DDA43B91BFDA49AA2F1E473732113E5DBE0A(_at_)mou1wnexm05(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
 "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:

Another example where SPF syntax comes unstuck.


[out of order reply:]
I don't think anyone can fairly claim that the spf ad-hoc syntax is going to
cope with this. OK you can define ad hoc extensions, but the number of
degree of freedom are huge.

On the contrary, I think that these are cases that can easily be
handled directly with the current SPF syntax. 

I don't see any difference between defining extensions as SPF
modifiers and defining new labels in the XML markup.


A domain uses S/MIME authentication [...]

The following information is needed:

      * express statement 'all mail is signed'

use the modifier: smime=always

      * express the message digest of the signing certificate

use the modifier: smime.certdigest=<location>

      * express the algorithm supported.

use the modifier: smime.alg=rsa


Or, just use:  smime-info=<location>


Now consider the following complications:

      * Also support pgp message format

Use the modifier:  pgp=allowed

      * express different signing policies 'mail signed when extension
offered'

I don't understand this one.

      * handle the TLS protocol

that is handled just fine with the MTA isn't it?

      * encryption

use the modifier: encryption=

      * different key distribution structures - web 'o trust, xkms, domain
key

use the modifiers:  webotrust=<location> xkms=<location> dk=<location>


One could argue that this should be handled by a separate record. But then
we are back to the two parsers option anyway. 

No, because the MTAs would not be *required* to support two (or more)
parsers.  Many of these options wouldn't require a new parser anyway.



-wayne