Here is the next set of comments:
1) Table 1: I hate to do it this way, but I don't think RSA is the correct
entry for Key Transport. Given that we know that RSA-OAEP is coming down
the road, I think that this should be renamed as RSA v1.5 or something
similar. I see a similar problem for signature algorithms and the note. See
comments 3 and 4 below.
2) Section 2.1: I believe that the MUST and SHOULD statements in this
paragraph are in conflict. ie. MUST encode as and SHOULD generate with.
These should be resolved as MUST in both locations.
3) Section 3: RSA is not a signature algorithm. RSA-SHA1 and RSA-MD5 are
signature algorithms. RSA is a public key algorithm.
4) Section 3/Table 1: From the requirements on digest algorithms I assume
that RSAwithSHA1 is a MUST and RSAwithMD5 is a SHOULD.
5) Section 3.1: Change to "The algorithms parameter field MUST be encoded
as absent."
6) Section 3.2: Boy we really messed this one up. Section 3.2 should occur
as two different sections one for RSAwithMD5 and one for RSAwithSHA1. I
will never understand how all of us missed this one.
The OIDs for this should be:
sha1withRSAEncryption (1 2 840 113549 1 1 5)
or
#define szOID_OIWSEC_sha1RSASign "1.3.14.3.2.29"
md5withRSAEncryption (1 2 840 113549 1 1 4)
This is interesting. the OIWSEC version is the one that I think I have
alwayed used (it's what I had for my own coding the the examples) but John
appears to be using the other one. I note that there also appear to be
atleast two OIDS defined for MD5 but I am sure everyone is using the one
above.
7) Section 4.1, para 2: There is a different in language here.
- if ContentEncryptionAlg MUST KEK Alg.
- SHOULD 3DES KEK
- SHOULD RC2 KEK
- MUST 3DES KEK on 3DES Content
- MUST RC2 KEK on RC2 content.
Let me make a new stab at this:
Keep para 1 from section 4.1.
The following is the rest of section 4.1:
A key agreement algorithm consists of the following items:
1. A shared secrect computation that takes the originator and receipient
keys and computes a shared secret.
2. A symmetric key derivation algorithm that uses the shared secret to
compute a symmetric key.
3. A key-wrap algorithm which uses the symmetric key generated by 2 to
encryption the CEK producing the value encded in the CMS kari structure.
Key agreement algorithm identifiers are located in the EnvelopedData
RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
keyEncryptionAlgorithm fields.
4.1.1 X9.42 Ephemeral-Static Diffie-Hellman
The shared-secret computation and symmetric key derivation algorithms for
Ephemeral-Static Diffie-Hellman key agreement are defined in RFC 2631
[DH-X9.42]. E-S D-H uses the KEK algorithms defined in section 4.3 for
the key wrap algorithm. ES DH MUST support the 3DES KEK for key wrapping.
ES DH SHOULD support RC2 KEK for key wrapping. When using Ephemeral-Static
Diffie-Hellman, the
EnvelopedData RecipientInfos KeyAgreeRecipientInfo and
AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are
used as follows:
...
keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm
<< Changed
identifier. The algorithm identifier parameter field for id-alg-
ESDH is KeyWrapAlgorithm, and this parameter MUST be present. The
<< Changed
KeyWrapAlgorithm denotes the key wrap algorithm used
<< Changed
to encrypt the content-encryption key with the pairwise key-
encryption key generated using the X9.42 Ephemeral-Static Diffie-
Hellman key agreement algorithm. The document uses the KEK algorithms
defined in section 4.3 as the key wrap algorithms. The KEK algorithm used
is defined in the KeyWrapAlgorithm parameter. The id-alg-ESDH algorithm
identifier and parameter syntax is:
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
KeyWrapAlgorithm ::= AlgorithmIdentifier
New requirement: When deriving a Triple-DES key, a three key Triple-DES key
MUST be derived. When deriving a Triple-DES key wrap key, the parity on
each of the three sub-keys MUST be correctly generated after the key
derivation process is complete.
8) Section 4.1, para 3: The MAY in the sentence "For example" should be may
or "can be used"
9) Section 4.3: The MAY in the sentence "For example,..." should be may or
"can be used".
10) Section 5: Type "MS implementations..." should be "CMS
implementations..."
11) Section 6.1: Should use MUST not must for the parameter encoding
statement.
12) Section 7: I do not believe this section needs any MUSTS for inclusion
of algorithms. That is covered in section 4.
13) Security Considerations: Change "The CMS" to either "CMS" or "The
Cryptographic Message Syntax (CMS)"
14) Security Considerations: I recomend "This document identifies a set of
cryptographic algorithms for use with CMS." - remove the word "the" as it
is not the entire set.
15) remove the paragraph on counter-signatures.
jim