Russ:
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Housley,
Russ
Sent: Tuesday, August 21, 2001 6:06 AM
To: jimsch(_at_)exmsft(_dot_)com
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.
[JLS]
1. MUST handle with a parameters of NULL
2. SHOULD accept absent parameters (as well as NULL)
3. SHOULD generate with absent parameters.
The MUST accept and the SHOULD generate are of opposite choices.
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.
[JLS] I don't have a problem with the statement above, it is when you
say CMS implementations... That I have a problem as that appears to be a
CMS requirement not an algorithm requirement. Please see response
message to Paul on this issue.
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.
[JLS] This is acceptable to me.
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.
[JLS] The salt issue addresses my concerns. I don't care about the
question of the NULL parameter, but do agree that is in the password
draft.
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.
[JLS] This addresses my problem. (And would be good SHA-1 text as
well.)
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 }
[JLS] Don't forget the semi-colon following the OID since there are no
other IMPORTS in the document.
[JLS] I would request that the PKIX module be used rather than the
X.509 since that is more widely available.
jim