John:
I just sent cmsalg-03 to the repository. The results of this discussion
will appear in cmsalg-04.
1) Sec 2, 3rd para: Please replace:
OLD: "Digest values are located in the DigestedData digest field the Message
Digest authenticated attribute."
NEW: "Digest values are located in the DigestedData digest field and the
Message Digest attribute."
Good catch. Done.
2) Sec 2.1, last para: In a message exchange between Jim and Russ, Russ
agreed to change the last paragraph in Sec 2.1 to the following:
The AlgorithmIdentifier parameters field is OPTIONAL. If present,
the parameters field MUST contain a NULL. Implementations MUST
accept SHA-1 AlgorithmIdentifiers with absent parameters.
Implementations SHOULD accept SHA-1 AlgorithmIdentifiers with absent
parameters. Implementations SHOULD generate SHA-1
AlgorithmIdentifiers with absent parameters.
I believe that the following paragraph would be better:
The AlgorithmIdentifier parameters field is OPTIONAL. If present,
the parameters field MUST contain a NULL. Implementations MUST
accept SHA-1 AlgorithmIdentifiers with absent parameters.
Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL
parameters. Implementations SHOULD generate SHA-1
AlgorithmIdentifiers with absent parameters.
Fine. Done.
3) Sec 3.2 specifies that the md5WithRSAEncryption or sha1WithRSAEncryption
OID should be used in the signerInfo signatureAlgorithm field instead of the
id-rsaEncryption OID. I agree with this strategy, but please note that this
is a change from what is specified in RFC 2630. RFC2630 specifies the use
of id-rsaEncryption in the signerInfo signatureAlgorithm field. Is this
change going to cause backwards compatibility problems with legacy CMS
implementations?
I want to highlight this point. As you say, it might be controversial. I
will start a thread to discuss this point.
4) Sec 4.1.1, please replace:
OLD: "CMS implementations MUST support ukm being absent, and CMS
implementations SHOULD support be present."
NEW: "CMS implementations MUST support ukm being absent, and CMS
implementations SHOULD support ukm being present."
Good catch. Done.
5) sec 4.1.2, originator field, please replace:
OLD: "In both cases, the recipient's certificate contains the sender's
static public key,"
NEW: "In both cases, the originator's certificate contains the originator's
static public key,"
Good catch. In PKCS #7, RFC 2630, and rfc2630bis-03, the term "sender" is
used in much of that narrative description. Therefore, I prefer:
originator MUST be either the issuerAndSerialNumber or
subjectKeyIdentifier alternative. In both cases, the originator's
certificate contains the sender's static public key, and the
certificate subject public key information field MUST contain the
dh-public-number object identifier:
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
6) sec 4.1.2, originator field, please add: "[PROFILE] specifies the
AlgorithmIdentifier parameters syntax and values that are populated in the
originator's certificate."
Is this correct? I think that it has been moved to the PKIX Algs document.
7) sec 4.3, 1rst sent: Please replace:
OLD: "This section specifies the conventions employed by CMS implementations
support symmetric key-encryption key management using Triple-DES or RC2
key-encryption keys."
NEW: "This section specifies the conventions employed by CMS implementations
that support symmetric key-encryption key management using Triple-DES or RC2
key-encryption keys."
Agree. Done.
Russ