ietf-smime
[Top] [All Lists]

Hashing of CMS signedData objects

1998-01-28 14:15:34
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.


<Prev in Thread] Current Thread [Next in Thread>