Re: AS#1 draft-ietf-ediint-as1-01.txt comments

[chucks@xxxxxxxxxxxxx (Chuck Shih)]

Carl Hage wrote:
> 
> No, the one way hash should be computed on the undecoded message contents
> immediately following the RFC822 message headers, i.e. the base64 decoded
> binary data, the quoted-printable text after the =XX "quotes" are removed,
> or the plain text message following the blank line after the headers.
> Lines following a terminating --separator-- are not included. This is the
> MIME "Content".  The Content-MD5 is such a MIC, but RFC1864 is flawed
> because it doesn't define the semantics for multipart or
> non-content-encoded "contents".
> 
> Computing the receipt hash doesn't use any S/MIME or PGP attributes, it
> would be a MD5, SHA, or some other one way hash.
> 
> The way this would work from a programming point of view is that the top
> level UA would parse the RFC822 message headers, find the receipt request,
> find the MIME headers, and the pass the MIME contents off for processing,
> dependent on the MIME types and filters, etc. A return status from the
> processing application would be used as a status in a receipt which is
> then generated. The MD5/SHA is computed as the contents are passed to the
> processing application. This works for any MIME type, including plain
> text messages for display, and works even if no automated processing is
> performed.
> 
 
> I'm suggesting using the same double MIME wrap for signed, then encrypted
> data, i.e. the same way PGP/MIME is used. This means the RFC822 MIME type
> will be application/x-pkcs7-mime, ContentInfo=EnvelopedData if encrypted,
> or multipart/signed if not encrypted. The ContentInfo=SignedAndEnvelopedData
> would not be used and application/x-pkcs7-mime, ContentInfo=SignedData
> would not occur in the RFC822 headers.
> 
> For all S/MIME signed data, the contents are always combined in a
> multipart/signed MIME wrapper, where the second part is the
> application/x-pkcs7-mime, ContentInfo=SignedData containing PKCS7 detached
> data form of signature.
> 
> What I mean by exclusion in S/MIME is the SignedAndEnvelopedData as well as
> non-detached form of signed data. (Non-detached, means the signed contents
> are embedded inside the PKCS7 binary data rather than wrapped in a MIME
> multipart.)
> 
> The reason for excluding SignedAndEnvelopedData, is so the message can
> be decrypted, and then stored with a signature, and to simplify the processing
> so only 1 of the 2 ways of wrapping are used. Maybe the restriction is
> unreasonable, and all possible forms are supported with "caveat emptor".
> 
> >


I'll agree with you on not requiring use of the SignedAndEnvelopedData,
since 
there have been other concerns voiced about the fact that the identities
of the
S/MIME signatories are left exposed, the issuer and serial number for
each
signatory is not protected, when using SignedAndEnvelopedData. Chrysler
and Bob Moskowitz 
had some vigorous objections to this. 

To protect the signatory information, use of a nested signed message
within an
enveloped (encrypted) message should be required with EDI. This brings
us to the
question of which form of signed message should be required, the
multipart/signed
or the signedData content type - both of which are supported by S/MIME.
I think 
you prefer using the multipart/signed format.

Is there any other opinion out there on which form of signed message
should be
required? I feel that using the signedData content type is easier to
implement
with existing tool-kits (opinions?). For use in EDI, if the EDI UA 
is compliant with this EDIINT draft, handling the signedData should not
be an issue. 
Being able to read the text portions of the EDI data should not be the
issue it is 
in secure e-mail: each trading partner will be required to have a
compliant 
EDI UA that supports the signedData, if and when this becomes a draft
requirement.  

Regardless of which format of signed data is supported I still don't
understand
how you can easily calculate the MIC on the "contents of the message."
Using either
one of the signed formats, the MIC calculation is still on some other
MIME
content. With the signedData the MIC is calculated on the inner Data
content,
which can be a 1767 EDI MIME content or perhaps a multipart MIME
content. Using
the multipart/signed format, the MIC is calculated over the first
content in the
multipart/signed. Calculating the MIC over the entire message contents
would 
require that the UA hash the signerInfo information when using the
signedData
format and lots of other header and boundary seperators in either
format. 

Would a hash of the entire message contents also include a MIC
calculated on the signature?

I guess the really confusing thing to me is where do you put the signed
MIC
when its calculated over the message contents? Are you suggesting that
the signed
message be built, a MIC calculated on the message contents excluding (or
including?) the
signature part. Once the MIC is encrypted (signed) then the signature
information is
then formatted/inserted into either signerInfo, or following the
application/x-pkcs7-signature
header - depending on which S/MIME format?