-----Original Message-----
From: Russ Housley [mailto:housley(_at_)spyrus(_dot_)com]
Sent: Wednesday, November 25, 1998 11:29 AM
To: Jim Schaad (Exchange)
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Comments on CMC-09
Jim:
4. Section 4.0 Last Paragraph: Please delete the last
sentence in this
paragraph. I don't understand what is going on in this
paragraph. We have
obously defined how to do the encapsulated content in this
document (such as
signed data in signed data), we just have not defined any
other base content
types
Agree. This was intended to allow arbitrary content types to
be encapsulated.
I agree that it does not belong in this section. Does the
thought belong
somewhere else?
Also, I added the Data ASN.1 definition:
The data content type shall have ASN.1 type Data:
Data ::= OCTET STRING
I agree with the addition of the ASN. I don't think the thought needs to be
expressed anyplace else. Neither of the sections for encapsulated or
enveloped content have any restrictions implied or explict about the content
to be encapsulated.
5. Section 2.0 Paragraph 1. Change "ContentInfo
encapsulates one or more
content types." to "ContentInfo encapsulates an identified
content type."
There is no sequence so the one or more is misleading.
I agree with your point. How about:
ContentInfo encapsulates a single identified content type, and
the identified type may provide further encapsulation.
This sounds fine with me.
6. Section 3.0 Should we change the title on this section
from General
Syntax to Content Info? Since we are no longer restricting
the exported
types to ContentInfo then there is no longer a single general syntax
anymore.
This is the title used by PKCS#7 v1.5. My hope is to make it
easier for the
reader who is concerned about backward compatibility.
What do other people think about this one?
9. Section 9.2: Was there a reason for removing the
"rather than the
implcit [0] .." phrase. This exists in the process for
signed data and I
think should be here as well.
For authenticated-data, digests are only computed on the
content. They are
never computed on the attributes. The IMPLICIT [0] stuff was
about the
attribute encoding.
I don't follow your response. What I am looking at is the text relating to
the creation of the authenticatedAttributes blob over which the MAC will be
computed. This is yet another location where the ASN which is encoded and
sent is not the same as the ASN which is acutally MAC-ed. I think this
should be very explicit like in the other cases.
10. Global -- You have some inconsitant labeling Some
references are
bracked and some are not. Please go through the document
and choose one
method or the other but be consistant. (Examples are 11.0
uses brackets but
10.2.2 does not.)
I changed 10.2.2. I did not see any others like that one.
I'll send you a list.
13. Section 12.3.1.1 Para "keyEncryptionAlgrothm must ..."
I have a problem
with the phase a "and contain a", the first 6 or 7 time I read this I
assumed it was a field in the parameters rather than being
the parameter
itself. Writing as "The algorihtm identifier parameter field for
id-alg-ESDH is KeyWrapAlgorihtm and must be present." avoids
this issue.
Okay. How about:
The algorihtm identifier parameter field for id-alg-ESDH
is KeyWrapAlgorihtm, and this parameter must be present.
This is just fine.
14. Section 12.3.3 Last paragarph. What is this paragraph
doing here? It
is talking about key agreement in the symetric key
-encryption section.
The output of a key agreement algorithm is a key-encryption
key, and this
key-encryption key is used to encrypt the content-encryption
key. The last
paragraph is a backward pointer telling folks that the same
techniques are used
regardless of the source of the key-encryption key. I will
add an sentence to
the front of this paragraph that hopefully makes this more clear.
I don't understand this even with your explination.
15. Section 12.6.2 - You have not modified the key wrap
algorithm to allow
for arbitrary length RC2 key sources.
Are you suggesting an explicit length field or something else?
We need to either put in an explicit length field or use a known padding
algorithm. I have no perference on which is used but something along this
lines is absolutely required.
16. Section 12.3.1.1 - In the KeyWrapAlgorithm is the IV
present and is its
value the constant 'A5' repeated n time? The IV was not
present in the
previous versions but would appear to be present now. We
still have the IV
restriction on the key wrap algorithm however.
There is no field needed to carry the IV as it is always
"A5...A5". For 3DES,
the parameter is always NULL, and for RC2 the parameter is
the effective key
length. Where do you see an IV?
OK -- I see where I got confused. I started with the second paragraph in
section 12.3.1 and made a leap of incorrectness into the fact that the
KeyWrapAlgorithm was going to be rc2-cbc not id-alg-RC2wrap. I don't see
any clarifications that need to be added to the text, I was just skimming
the changes too fast.
Russ
jim