Re: cryptographically verifiable fields

James M Galvin 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.
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.
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. Some people 
distribute public
   keys via finger service or via a web site, but that generally 
involves manual intervention
   to make the keys available to authentication software.  If an email 
address serves as an
   identifier for the purpose of authorization, then perhaps an SMTP 
extension could be
   used to retrieve a public key corresponding to that email address -- 
but that's just a
   thought.  Of course, given a distributed authorization database, 
public keys could be
   part of that.  The SMTP extension idea might be useful where 
authentication is needed
   but authorization is not.

The same sort of solution might be useful in email.  Assuming a viable 
means of signing
non-trace header fields plus message body, and availability of an open 
automated mechanism
for obtaining public keys, signed email which is fully compatible with 
existing MTAs and MUAs
could quickly become popular. Without a multipart/signed wrapper, such a 
message could
be read by existing MUAs.  Enhanced MUAs/MTAs could handle signed 
messages as follows:
1. author composes message, MUA (or possibly submission MTA) computes a 
hash over non-trace
   header fields plus body and adds a header field consisting of that 
hash encrypted with the
   user's private key (and possibly transfer-encoded for robustness).
2. MTAs transfer message as usual, adding trace fields.
3. recipient's MUA checks for header field containing encrypted hash:
  a) no field: message is not signed (or hash field has been lost in 
transit)
  b) encrypted hash field is found: MUA queries DNS for MX records 
corresponding to sender
      envelope address, then opens connection to an SMTP server to 
retrieve public key, finally
      attempts authentication by decrypting hash and verifying that 
hash is valid
      i) if hash is valid, message is authentic and unchanged (with a 
high degree of probability)
      ii) if hash is not valid, message is forged or has been modified 
in transit
      iii) in case of DNS or SMTP problems, authenticity cannot be 
established.
Obviously such a scheme requires support in MUAs (possibly submission 
MTAs), and SMTP
servers.  If submission MTAs are used for generation of the encrypted 
hash, ISPs could
implement the necessary mechanisms with the exception of MUA 
authentication support
(the ISP would generate a key pair for each email address, using the 
private key for
encryption and returning the public one in response to the SMTP 
extension request; all
of that could be handled transparently to computer-illiterate end users).

#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################