James M Galvin wrote:
So, here's a suggestion for how to use encapsulation in a backwards
compatible way. Actually, it is transitionally backwards compatible
since it presumes the ultimate goal is to "upgrade" to using
encapsulation.
Presumably the "backward" sites would not honor a Content-Type: header
if it was present in a control message. So, use the multipart/signed
solution but duplicate the text in the signed object in the preamble of
the body, i.e., before the first boundary marker.
"Backward" sites get what they expect and "forward" sites use the
enhanced features.
In some cases that might work, however the "backward" software might not
stop
processing at the multipart boundary delimiter.
There are a number of other issues that would have to be addressed
in the Usenet examples:
1. Authorization; a mechanism for distributing and updating
authorization information (who is authorized to approve a
moderated article, or to issue control messages) is needed.
Is this more complicated than adding a new protocol element to a control
message, i.e., a new type control message?
I think that becomes a "chicken-and-egg" problem: if a control message
provides authorization
information, why should I trust that control message -- is it
authorized? Some root source(s) of
authorization information would have to be established by some other
mechanism. Probably
not a big problem.
2. A standardized open mechanism for obtaining information necessary
to complete authentication. Aside from cost issues, some people
are leery of dealing with CAs, especially after last year's
Verisign DNS shenanigans.
So you're in need of a "PKI", essentially. Well, if we had DNSSEC you
would have one, ideally suited for this application since given an email
address you've got all the information you need for a lookup and the
machinery to do it.
Yes. Hmm...