I don't see any need to support the ASN for the old way in the current
CMS spec. What I want to do is just to document what the old way was
and give to implementers how verification would be done if they wanted
to support it. I don't see any reason to polute the pure CMS spec with
this. Putting a reasoning, explication and algorithm in an appendix of
the CMS document is more than sufficient for me.
I think that the number of people who are going to really want to
implement this is very small, most people just have either data objects
or will be using the new version. I just want to document what is going
on (if you want to provide alternate ASN thats fine) so that developers
who run across this old stuff that they cannot tell from the new stuff
except it does not parse will not die.
jim
-----Original Message-----
From: Russ Housley [mailto:housley(_at_)spyrus(_dot_)com]
Sent: Sunday, February 01, 1998 11:21 PM
To: Jim Schaad (Exchange)
Cc: Ietf-Smime (E-mail)
Subject: RE: Hashing of CMS signedData objects
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.