Graeme:
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?
Russ
At 05:16 PM 8/15/2001 +0100, Graeme Lunt wrote:
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