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