ietf-smime
[Top] [All Lists]

RE: Hashing of CMS signedData objects

1998-02-05 08:31:21
John:

I realize the ramifications.  I am wondering if it is worth the pain to
support the non-S/MIME implemnattions that previousley used PKCS#7 v1.5 to
protect arbitrary content types.

Russ


At 05:47 PM 2/2/98 -0500, John Pawling wrote:
Russ,

This leads to the following logic for the receiving agent:

"IF CHOICE == OLD WAY THEN

   IF contentType == id-data THEN hash value field of owContent OCTET STRING

   ELSE hash DER-encoded owContent 

ELSE hash value field of nwContent OCTET STRING"


If we went with the proposal in San Francisco (see below), then the content
is always an OCTET STRING, so the rule is simply: "Always hash value field
of content OCTET STRING".


In summary, I believe that CMS should mandate the strategy that was agreed
to at San
Francisco as follows:

"Proposal #2: Change the CMS SignedData contentInfo field to be
signedContentInfo defined as follows:

SignedContentInfo ::=  SEQUENCE {
   sigContentType       ContentType,
   sigContent      [0]  EXPLICIT  OCTET STRING  OPTIONAL}

It is proposed that the CMS Section 5.3 will be changed so that the
digesting rules are consistent for all types of data that is signed (i.e.
the rules for digesting the Data content type will be extended to all types
of data)."

- John Pawling


At 02:20 AM 2/2/98 -0500, Russ Housley wrote:
Jim:

Would this help?

... CHOICE { TheOld Way, TheNewWay }

theOld Way ::= SEQUENCE {
 contentType ContentType,
 owContent [0] EXPLICIT ANY DEFINED BY contentType }

theNewWay ::= SEQUENCE {
 contentType ContentType,
 nwContent OCTET STRING }

Then, we tell everyone that defines a new content type to follow the New Way
syntax?

I am just brainstorming here.  So, feel free to flame.

Russ


At 12:08 AM 1/31/98 +0000, Jim Schaad (Exchange) wrote:
Yes all of the objects have their own OIDs so that they are
recognizable.  I would not however wish to enumerate the list and
special case in that way.

jim


-----Original Message-----
From: Russ Housley
[<mailto:housley(_at_)spyrus(_dot_)com%5D>mailto:housley(_at_)spyrus(_dot_)com]
Sent: Friday, January 30, 1998 5:40 AM
To: Jim Schaad (Exchange)
Cc: Ietf-Smime (E-mail)
Subject: Re: Hashing of CMS signedData objects


Jim:

I need more information.  Do these objects have their own OIDs?  If so,
there may be a straightforward way to support them. 

Russ


At 01:20 PM 1/28/98 -0800, Jim Schaad (Exchange) wrote:
When we had the discussions in San Fransico at the RSA conference, one
of the questions that was raised about changing the what data and how
the data was encoded was if there was any material currently out in the
real world which was signed in the PKCS #7 way rather than the new
proposed CMS way.  At the time I said that I know of none.  I have
since
been informed that MIcrosoft actually does have some objects signed and
encoded in this manner, and they have actually been released into the
real world.

This gives a problem to me because it means that I need to have atleast
some backwards compatable language put into the CMS draft.  Thus I
propose the following:

We add an appendix to the CMS draft to explain the following items:
1.  The difference and reasons for the change in the way that the data

is encoded.
2.  A general way of doing recognition of the two different ways of
encoding and how to correctly verify each way
3.  A statemtent that one MAY implement the compatibilty mode of
signature verification and one SHOULD NOT implement the compatability
mode of signature creation unless required to do so by backwards
compatability issues.

How to do both signature verifications:

Look at the type of the data enclosed.  
-  If it is octet string then strip the type and length encoding bytes,
allowing for the possilbity that it may be indefinite lenght encoded,
and hash the remaining data.  The data actually hashed is then returned
as the data block of signedData object.
-  If it is not octet string, then strip the type and length encoding
bytes (can't be indefinite length encoded) and hash the remaining data.
The data returned as the data block of the signedData object is the
type, length and hashed data.