Jim:
1. Introduction: CMSALG cannot have a protocol requirement on CMS.
Please lowercase MAY statements in the first paragraph of the
introduction.
Here is what RFC 2119 says about MAY:
MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)
I believe that this is a statement about the things specified in the CMSALG
document. CMS implementations can choose to implement them, or not. I
think that MAY is the correct word and case.
2. Section 2.1: There is a conflict between MUST in the next to last
and SHOULD in the last paragraph for handling the presence of NULL
algorithm parameters.
I have read it three times, and I do not see the problem. The working
group decided that the transmission of omitted parameters and NULL
parameters are both legal. Therefore, implementations SHOULD be able to
process both. However, if parameters are present, they must contain NULL.
Please post a proposed working change if you still think that there is a
problem.
3. Section 3.2: The paragraph "CMS implentations that support ..."
should be removed. This is a protocol statement on CMS not CMSALGs.
I do not agree. If an implementation chooses to implement RSA (PKCS#1
v1.5) signatures, they MUST also implement SHA-1. Such implementations
SHOULD also support MD5. There is nothing in this document that forces an
implementation to support RSA (PKCS#1 v1.5) signatures.
4. Section 4.1: I think that the following sentence should be removed
from the text. I have two problems with this statement. First, it is
imposing a MUST on a CMS implementation rather than on algorithms.
Second, a protocol that requires only RSA and 3DES does not need to
require 3DES-WRAP as well.
"Any symmetric encryption algorithm that a CMS implementation includes
as a content-encryption algorithm MUST also be included as a
key-encryption algorithm."
That said, I do think that a variation of the criteria should be stated.
"When a key agreement algorithm is used, a key-encrytion algorithm is
also required. In this case a key-encryption algorithm MUST be provided
for each content-encryption algorithm."
I agree. I propose the following alternative for the subject paragraph:
When a key agreement algorithm is used, a key-encryption algorithm is
also needed. Therefore, when key agreement is supported, a key-
encryption algorithm MUST be provided for each content-encryption
algorithm. The key wrap algorithms for Triple-DES and RC2 are
described in section 7.
5. Section 4.1: "A CMS implemenation MAY support mixed..." This
paragraph should be moved into the description of each key-wrap
algorithm. Thus "3DES-Wrap implementations MAY support wrapping of
non-3DES keys."
Okay. Done.
6. Section 4.1.1: "ukm MAY be present or absent." I think this makes
no sense from a protocol sense. I believe that one implemenation could
require presence and another could require absense thus leading to
non-interopability. I had thought the requirements on this was going to
be "ukm may be either present or absent. Implemenations MUST support
ukm being absent and SHOULD support be present."
Okay. Done.
7. Section 4.1.1: description of keyEnryptionAlgorithm.
"KeyWrapAlgorihtm" is misspelt.
Good catch. Fixed.
8. Section 4.4, Para 2: This contains a MUST on CMS. It needs to be
removed.
You are correct. I deleted the sentence with MUST in it.
9. Section 4.4: Some of the PBKDF2 restrictions from the password
draft have been lost:
A) Only the salt CHOICE requires support
B)
I looked through the password-04 draft, and I think that I have covered all
of the MUST statements. Therefore you must be talking about the ASN.1. It
says:
PBKDF2-params ::= SEQUENCE {
salt OCTET STRING,
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier
DEFAULT { algorithm id-hmacWithSHA1, parameters NULL } }
However, I pulled the syntax from PKCS #5, and they do not match. The one
is password-04 is a legal subset. The one in CMSALG is:
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING,
otherSource AlgorithmIdentifier },
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier DEFAULT hMAC-SHA1 }
I added two things. First, I added the setting of the default algorithm
parameter to NULL. Second, I added the following sentence about salt:
Within the PBKDF2-params, the salt MUST use the
specified OCTET STRING.
10. Section 6.1: Last paragraph should have MUST not must.
Due to the inclusion of the NULL parameter in response to your comment
number 9, I rewrote almost the whole section. It now says:
6.1 HMAC with SHA-1
The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The
algorithm identifier for HMAC with SHA-1 is:
hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
There are two possible encodings for the HMAC with SHA-1
AlgorithmIdentifier parameters field. The two alternatives arise
from the fact that when the 1988 syntax for AlgorithmIdentifier was
translated into the 1997 syntax the OPTIONAL associated with the
AlgorithmIdentifier parameters got lost. Later the OPTIONAL was
recovered via a defect report, but by then many people thought that
algorithm parameters were mandatory. Because of this history some
implementations encode parameters as a NULL element and others omit
them entirely. CMS implementations that support HMAC with SHA-1 MUST
handle both an AlgorithmIdentifier parameters field which contains a
NULL and an AlgorithmIdentifier with an absent parameters.
11. ASN Module:
cmsalg.asn(124) : error 1019: Type symbol AlgorithmIdentifier never
resolved.
I added:
IMPORTS
-- Directory Authentication Framework (X.509-2000)
AlgorithmIdentifier
FROM AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 4 }
Russ