[Top] [All Lists]

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

2001-08-16 06:42:42


Before this approach was adopted, we asked several implementors if their toolkits would handle this sort of nesting. Not a single implementor expressed concern at that time. Do you have new information for us?


At 05:16 PM 8/15/2001 +0100, Graeme Lunt wrote:


> 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
from Decrypt()).

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

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



<Prev in Thread] Current Thread [Next in Thread>
  • RE: Comments on draft-ietf-smime-x400wrap-03.txt/draft-ietf-smime -x40 0transport-03.txt, Housley, Russ <=