On Mon, 19 Jan 2004, Bruce Lilly wrote:
>This is where I think multipart/signed got it right and is a big win (he
>says with all humility :-). There are only two real requirements.
>
> the object to be signed must be canonicalized
>
> it must be universally representable
>
>
[...]
>Now, if you're looking to add a signature (or some other cryptographic
>trace value) to the outermost headers and have it apply over the entire
>message (including the outermost headers), then you've got a really hard
>problem.
>
>Actually, I don't think "really hard problem" begins to describe just
>how hard it would be. I can not imagine why anyone would want to do
>such a thing. It just isn't practical in today's Internet email
>environment.
>
>S/MIME and PGP/MIME inherit this to the extent they use
>multipart/signed.
One problem with encapsulation is that the signed information *is*
encapsulated. That's fine for an end-to-end application, but
doesn't work well for a message that needs to be validated and
interpreted at multiple points. Examples of the latter would be a
Usenet control message, or a Usenet article posted to a moderated
group. In each case, some of the message header fields and the body
would be signed, while fields which are expected to change in
transit (trace fields) would not be signed. Avoiding encapsulation
permits backwards compatibility; existing software can handle the
message with the same lack of authentication that is currently the
case, while newer software can verify authenticity. With
encapsulation, everything has to be rewritten to look inside the
wrapper.
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.
I think Keith's outline of a solution is viable.
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?
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.
Key management and distribution is never easy. Maybe we can "borrow"
something from other protocols that have had to deal with this
problem, or move forward with what you proposed as a basis.
Jim