ietf-smime
[Top] [All Lists]

RE: Comments on draft-ietf-smime-x400wrap-03.txt/draft-ietf-smime -x40 0transport-03.txt

2001-08-15 09:17:16

Anders,

I have given an explanation below for why we removed some of the  
ContentInfo wrappers in the steps for tripple wrapping of an X.400 
content. 

Thanks for the feedback.

Since we don't have the MIME wrappings, we don't need the ContentInfo 
wrappings either. The ContentType OIDs in SignedData and EnvelopedData 
will identify the encapsulatet content (or content type).  ContentInfo 
needs only to be used around the outer most SignedData because this is 
required by PKCS #7 and CMS.   
The ContentInfo wrappings will only introduce an unnecessary level of 
indirection, and you will have to modify your ESS code for SMTP anyway 
because the MIME wrappers are gone.  Thus, a triple wrapped message will 
have the following form: 
         X.400 Envelope  ->  id-ct-contentInfo 
         ContentInfo     ->  id-signedData 
         SignedData      ->  id-envelopedData 
         EnvelopedData   ->  id-signedData 
         SignedData      ->  <OID for content type> 
If you want to produce a "signed-only" version of a triple wrapped 
message, all you need to do is to wrap the inner most SignedData in a 
ContentInfo and forward it which should be a pretty easy operation.

I agree entirely that the ContentInfo wrappings are not needed as you can
carry all the information required in the structure you outline.

I just think that ContentInfo are more generic and what I might expect
toolkits to actually process as their basic unit e.g. a Verify() function
is likely to take a ContentInfo - as I can use it for the outer signature 
(passing the raw content) or the inner signature (passing the content
returned 
from Decrypt()).

The Verify() function may, of course, just take a signed-data, but it is
more
straight-forward to seek to the Signed-Data in the Content-Info ASN.1
stream, 
rather than wrap up the Signed-Data ASN.1 into a Content-Info ASN.1
(especially
for large messages).

Anyway, the current draft is workable - I'm just trying to understand the
change.

Thanks,

Graeme


<Prev in Thread] Current Thread [Next in Thread>