Subject: CMS Implementation Questions

From: Jack Lloyd <[email-masked]>
Date: Thu, 13 Nov 2003 07:21:27 -0500 (EST)

I've been looking over the various CMS RFCs, and have a few questions, most
of which probably have obvious and simple answers, but I could use some
help.

1) I'm pretty sure I understand how to nest CMS structures correctly, but the
   existing S/MIME examples draft doesn't have any examples of, say, compress
   then encrypt then sign. Are there any examples floating around, or, are
   there any free implementations of CMS that do this, which I could use to
   generate a few tests? (Preferably PEM or raw binary, rather than MIME, but
   I'll take what I can get).

2) In section 6.2.3 of RFC 3369, "keyIdentifier identifies the key-encryption
   key that was previously distributed to the sender and one or more
   recipients." Is there some typical mechanism for choosing this value?
   Obviously, as far as the RFC is concerned, one can do pretty much anything
   they please, but if there is a simple and commonly used method, I figure I
   might as well go with the crowd.

3) It is legal to include SignedAttributes and sign everything that way even
   when signing plain data content, correct?

4) Is the encoding of subjectKeyIdentifier in SignerIdentifier and
   RecipientIdentifier supposed to be with EXPLICIT or IMPLICIT tags? This is
   not particularly clear to me from the texts of RFCs 2630 and 3369.

5) Is the RC2 key wrap example in RFC 3217 right? For the KEK/IV/LCEKPADICV
   given there, I get:
      03 5E 97 2A B1 5C C4 C9 C4 A0 3D BA A3 5A 21 66
      67 E4 3E BC A2 67 46 AE 86 08 DB C8 9E 64 CA 29
   for TEMP1. I found a mention of at least one other person who had the same
   problem, and am wondering if the RFC is incorrect, or if my RC2 code manages
   to pass ~30 test vectors while still being wrong. Either way, something
   needs fixing.

Any help would be much appreciated.

Jack

---

From: "Bonatti, Chris" <[email-masked]>
Date: Mon, 17 Nov 2003 11:24:49 -0500

To take on a couple of the questions that Peter didn't address...

Jack Lloyd <[email-masked]> writes:

> 3) It is legal to include SignedAttributes and sign everything
>    that way even when signing plain data content, correct?

Yes, this is basically what SignedData is for.  %-}
Maybe I'm not grokking the question.

>    RecipientIdentifier supposed to be with EXPLICIT or IMPLICIT
tags?
>    This is not particularly clear to me from the texts of RFCs
2630 
>    and 3369.

IMPLICIT.

The module in clause 12.1 of RFC 3369 defaults to IMPLICIT
tagging, and nothing in the definitions of SignerIdentifier or
RecipientIdentifier override this default.  In both instances,
this means that the context-specific tag [0] replaces the OCTET
STRING tag.

Maybe somebody with RC2 code in front of them can address
question 5.

Chris

---

From: Jack Lloyd <[email-masked]>
Date: Mon, 17 Nov 2003 13:09:48 -0500 (EST)

> Maybe I'm not grokking the question.

When signing something other than plain data content, using the attributes
is required (section 5.3 of 3369). Otherwise, they are described as
"optional"; I'm presuming this means an implementation MAY use signed
attributes when signing plain data content as well? It is all-in-all fairly
clear, but I would prefer being 100% certain I know what it's trying to
say. When an RFC isn't completely and totally clear, I don't like to just
assume I'm guessing the correct interpretation.

> this means that the context-specific tag [0] replaces the OCTET

I saw the default tagging, but given the ease of mixups, I wanted to be
sure. There is lots of stuff in the module with explicit IMPLICIT tags,
which shouldn't really have to be there given that is the default encoding.
Sometimes IMPLICT tags are there, sometimes they are not. See last sentence
of my previous paragraph.

Thanks,
 Jack

---

From: "Bonatti, Chris" <[email-masked]>
Date: Tue, 18 Nov 2003 10:30:10 -0500

Jack Lloyd <[email-masked]> writes:
> When signing something other than plain data content, using 
> the attributes is required (section 5.3 of 3369). Otherwise, 
> they are described as "optional"; I'm presuming this means an 
> implementation MAY use signed attributes when signing plain 
> data content as well? It is all-in-all fairly clear, but I 
> would prefer being 100% certain I know what it's trying to 
> say. When an RFC isn't completely and totally clear, I don't 
> like to just assume I'm guessing the correct interpretation.
> 

The 'signedAttrs' field is an old function that goes back to
PKCS-7 (i.e., the 'authenticatedAttributes' field).  It has
always been an option to include signed attributes in the
signature regardless of the type.  I think the reason for the
requirement to include these for content types other than id-data
stems from the desire to have the PKCS-9 'ContentType' attribute
included to bind the type to the data.  There has always been a
perception that MIME content was the "default" for PKCS-7.  This
is supported by the fact that a MIME object is easily recognized,
and self-identifies what type(s) it carries.  This is not true
for many other possible object types.  I think that the
requirement to include the 'ContentType' attribute originally
comes from PKCS-9, though, not PKCS-7.  There is no converse
requirement to omit signed attributes when signing MIME data.

I hope this helps.

Chris