[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

Graeme,

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.

>-----Original Message-----
>From: Graeme Lunt
>To: ietf-smime@xxxxxxx
>Cc: 'julianonions@xxxxxxxxxxx'; Tim Freestone
>Sent: 08.08.01 10:03
>Subject: Comments on draft-ietf-smime-x400wrap-03.txt/draft-ietf-smime->x40 0transport-03.txt
>
>
>Paul,
>
>A couple of comments on the two drafts:
>
>x400wrap-03:
>
>I note that section 3.4.1 "Creating a Triple Wrapped Message With
>An X.400" has been changed so that a ContentInfo
>wrapping is no longer applied to the inner signed-data and
>enveloped-data (end of step 3, end of step 4).
>
>I can see that it saves me some bytes/redundancy in the encoding,
>but maybe you could give me some background to this change?
>
>I have a preference for keeping the contentInfo wrapping as:
>
>a) it to some extent aligns with S/MIME ESS, where at each similar
>stage a MIME construct is added (with a smime-type), and a generic
>object (id-data) is passed to the next level of wrapping. In the
>previous version the ContentInfo was the "generic" form that was
>subject to the next protection operation.
>
>
>
>b) it is simple to produce a "signed-only" version of a triple wrapped
>message e.g. for forwarding, as removing outer two wrappers should give
>me the appropriate form I require for a forwarded content bodypart.
>
>c) it just appears to me to be a more generic, simpler solution.
>ContentInfo encodings are what I am mostly likely to deal with e.g. in
>files
>
>(although having a slightly larger encoding).
>
>
>
>Comments?
>
>Graeme
>

In the ESS tripple wrapping decription, all of the nested "contents" are MIME wrapped and the ContentInfo wrappings are needed to identify the

content (or content type) under the MIME wrappings. The MIME wrappings are neccesary in SMTP systems for backwards compatibility with S/MIME version 2. In section 1.4 we explain why we don't need bacwards compatibility with S/MIME v.2. and for that reason we did not see the need to have the MIME wrappings (for a tripple wrapped message they add over 300% overhead).

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.

Best Regards

Anders