Russ:
-----Original Message-----
From: Russ Housley [mailto:housley(_at_)spyrus(_dot_)com]
Sent: Tuesday, January 12, 1999 11:36 AM
To: Jim Schaad (Exchange)
Cc: Ietf-Smime (E-mail)
Subject: Re: Last Call Comments on CMS-10
Jim:
1. Section 2, Last paragraph, Sentence 4: I think that
"However, signed
attributes within the signed-data content type and
authenticated attributes
within the authenticated-data content type require DER
encoding." should
read "However, signed attributes within the signed-data content type
andauthenicated a attributes within the authenticated-data
content type are
the only places where DER encoding is required."
I prefer:
... However, signed attributes within the signed-data
content type and
authenticated attributes within the authenticated-data
content type require DER
encoding. Signed attributes and authenticated attributes
must be transmitted
in DER form to ensure that recipients can validate a content
that contains an
unrecognized attribute. Signed attributes and authenticated
attributes are the
only CMS data types that require DER encoding.
This wording is great.
3. The algorithm OIDs defined and used in section 12 are not
included in the
ASN module.
I know. This is a philosophy question. Since these identifiers will
eventually be in the IANA registry, I did not know whether or
not these values
should be part of the module.
I would be glad to add these values to the module if the
working group thinks
they belong there. Comments?
4. Section 5, First pagagraph after the bullets. The text
has not been
updated to reflect the SKI addition to the signer info object.
Good catch. How about:
... The signer's public key is referenced by an issuer
distinguished name along with an issuer-specific serial
number or a subject key identifier that uniquely identify
the certificate containing the public key.
Wording is good, but I would like "is referenced either by".
7. Section 5.1: Text on version needs to be expanded to
deal with SKI.
Must be 3 if any SignerInfo version is 3.
Are you saying that a version 3 SignerInfo should cause
parent SignedData
version to be 3?
Is there a reason to prohibit version 3 SignerInfo from being
encapsulated in a
version 1 SignedData?
This is the backwards compatability thing. Everywhere else we have done --
you get a new version all the way up (See EnvelopedData) if you do something
new on an inner object. This prevents you from starting something you may
regret. If we don't do this here, then I don't see why we should be doing
it in EnvelopedData. I don't care which of the two we correct, but make
them consistant.
10. Section 12.3.1, paragraph 3. I would like to change the
first sentence
to "A CMS Implementation should support mixed key-encryption and
content-encryption algorithms."
Disgree. I am reluctant to change "may" to "should." What
do other people
think?
11. Section 12.3.3 - Please insert the following paragraph
in this section
" A CMS implementation should support mixed key-encryption
and content-
encryption algorithms. For example, a 128-bit RC2
content-encryption
key may be wrapped with 168-bit Triple-DES key-encryption key.
Similarly, a 40-bit RC2 content-encryption key may be wrapped with
128-bit RC2 key-encryption key."
As with comment 10, I would like to hear what other people
think before
changing "may" to "should."
Can I at least get you to agree to put in the paragraph with the "may"
syntax even if I get no support for "should"?
12. Ditto 11 for section 12.6
Ditto. As with comments 10 and 11, I would like to hear what
other people
think before changing "may" to "should."
Russ
jim