Re: Correct definition of ContentInfo in CMS-10

Brian Korver <briank@cs.stanford.edu> Mon, 22 February 1999 16:21 UTC

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA20153 for ietf-smime-bks; Mon, 22 Feb 1999 08:21:12 -0800 (PST)
Received: from oe8.briank.com (oe8.briank.com [209.133.59.211]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA20149 for <ietf-smime@imc.org>; Mon, 22 Feb 1999 08:21:08 -0800 (PST)
Received: from cs.stanford.edu (blatz.briank.com [209.133.59.212]) by oe8.briank.com (8.8.8/8.8.8) with ESMTP id IAA12600; Mon, 22 Feb 1999 08:24:52 -0800 (PST) (envelope-from briank@cs.stanford.edu)
Message-ID: <36D184D1.EBA99DB4@cs.stanford.edu>
Date: Mon, 22 Feb 1999 08:24:50 -0800
From: Brian Korver <briank@cs.stanford.edu>
Reply-To: briank@cs.stanford.edu
X-Mailer: Mozilla 4.5 (Macintosh; I; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: William Ottaway <w.ottaway@eris.dera.gov.uk>
CC: "'ietf-smime@imc.org'" <ietf-smime@imc.org>
Subject: Re: Correct definition of ContentInfo in CMS-10
References: <01BE5E63.4E934480.w.ottaway@eris.dera.gov.uk>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smime@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

William Ottaway wrote:
> 
> Within the body of CMS 10 ContentInfo is defined as : -
> 
> ContentInfo ::= SEQUENCE {
>         contentType ContentType,
>         content [0] EXPLICIT ANY DEFINED BY contentType }
> 
> However, in the appendix ContentInfo is defined as : -
> 
> ContentInfo ::= SEQUENCE {
>      contentType ContentType,
>      content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
> 
> I assume the one within the body (i.e. content not optional) is correct.
> 
> Bill.

In PKCS#7, content is OPTIONAL.  But now with EncapsulatedContentInfo, CMS
doesn't use ContentInfo anyplace but the outer wrapper.

I'd be inclined to leave it OPTIONAL (I mean, what does it hurt?).  S/MIME
might not need it, but someone else might....