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

From: "Eggen, Anders" <[email-masked]>
Date: Mon, 13 Aug 2001 23:34:17 +0200

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: [email-masked]
>Cc: [email-masked]'; 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

---

From: Graeme Lunt <[email-masked]>
Date: Wed, 15 Aug 2001 17:16:26 +0100

Anders,

> ContentInfo wrappers in the steps for tripple wrapping of an X.400 

Thanks for the feedback.

> 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.   

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

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 16 Aug 2001 09:32:03 -0400

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

---

From: Graeme Lunt <[email-masked]>
Date: Fri, 17 Aug 2001 10:23:41 +0100

Russ,

> 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?

No - my point was generic rather than specific - and seeking to
understand the background to the change. It appears to be to
save redundant encoding/bytes. 

I have not reviewed all the toolkits so can't comment on their
support. (FYI: the toolkit we are using is the SFL which does 
allow us to pass in signed-data and enveloped-data, and does
not require a Content-Info wrapper.)

As a user of the toolkit, rather than I provider, I need to be
able to handle the nesting, rather than expecting the toolkit
to do it for me.

For example, after validating the outer signature and retrieving the
ESS label, I want to check that the user is cleared for that label 
before going on to decrypt the next level.

Graeme