-----Original Message-----
From: Housley, Russ [mailto:rhousley(_at_)rsasecurity(_dot_)com]
Sent: Wednesday, June 06, 2001 1:36 PM
To: jimsch(_at_)exmsft(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Comments: draft-ietf-smime-rfc2630bis-00
Jim:
Thanks for spending so much time with the document. You have
performed a
real service here. I think that the bulk of your comments
are handled
here. There are a few that need further dialogue.
1. "The CMS ..." should be uniformly changed to "CMS ...".
I think that "The Cryptographic Message Syntax (CMS) ..." is
correct. Are
there places that I omitted "the"?
Actually I have no problems with "The Crryptographic Message Syntax (CMS)".
However as I look at the abstract for draft -00, the second paragraph starts
"The CMS is derived from PKCS#7 ..." In doing searches of the draft the
phrase "the CMS" is quite common. I count 5 that should be altered.
2. I have a sever problem with the following text "However,
implementations
of the CMS MUST support the mandatory to implement
algorithms specified in
[CMSALG], or its successor." It is my believe that this
statement should be
removed for the following reasons:
a) This violates the letter and spirit of the IETF process rules for
pushing documents to standards. In my opinion if this
becomes a standard
then CMSALG must also be a standard. Also if CMSALG is
reset to draft, so
must this draft. The words "MUST support" is extremely normative.
b) If I create a toolkit or other system and publish that I
am STD [CMS]
conformant. It does not make sense that by updating the set
of required
algorithms I loose conformance to that standard. I was
compliant, I loose
compliance through no action of mine. This argues that a
new standard
number should be applied.
c) The reasoning behind not having a MUST for certificates
is even more
strongly appliciable here. While certificates and
heirarchies can move
between different applications (thus making the arugment
that application
spaces should mandate algorithms a somewhat odd argument),
that is not the
case with CMS objects. If S/MIME and CMS/SET were to specificy that
different content encryption algorithms be required, there is no
interactions between the spaces. An S/MIME message would
never be consumed
(successfully) by a CMS/SET application nor would one expect
it to be used.
From this standpoint I think that not requiring a MUST on
algorithms from
CMS makes sense.
I have asked Jeff and Marcus for guidance. So far, I have
not received input.
We will see what happens.
5) Section 2, para 3: Revert to original language on DER
encoding of signed
and authenticated attributes. The correct location for the
MUST statement is
in the description of the attribute fields in the
appropriate structures.
I thought that the rewording removed the "must." We agree
that the MUST
statement belongs in the discussion of signed attributes and
authenticated
attributes. How about this:
As a general design philosophy, each content type permits
single pass
processing using indefinite-length Basic Encoding Rules (BER)
encoding. Single-pass operation is especially helpful if
content is
large, stored on tapes, or is "piped" from another
process. Single-
pass operation has one significant drawback: it is difficult to
perform encode operations using the Distinguished Encoding Rules
(DER) [X.509-88] encoding in a single pass since the
lengths of the
various components may not be known in advance. However, signed
attributes within the signed-data content type and authenticated
attributes within the authenticated-data content type need to be
transmitted in DER form to ensure that recipients can verify a
content that contains one or more unrecognized attributes. Signed
attributes and authenticated attributes are the only CMS
data types
that require DER encoding.
This is fine.
6) Section 5, para 8: The MAY should be lower case. This section is
descriptive in nature is not creating requirements on the
implementor.
Agree. How about:
The signer's certificate can be included in the SignedData
certificates field.
This is fine.
7) Section 5.1, digestAlgorithms: One of the following
statements should be
added to this paragraph:
a) Each digest algorithm used in a signture computation MUST
be included in
this set, although unused algorithms may also be included. OR
b) Complient implementations MUST verify signatures for
which the digest
algorithm is not in this set. OR
c) Complient implementations MAY fail signature verification
if the digest
algorithm is not included in this set.
How about:
Implementations MAY fail to validate signatures that use a
digest algorithm that is not included in this set.
I am more that happy with this this. It was my perfered answer.
8) Section 5.1, certificates: The following items are
missing from this
paragraph. 1) If version 2 attribute certificates are
present the version
MUST be 4. 2) The MAY from section 5, para 8 if it is considered of
importance. I think it can be omitted.
How about:
certificates is a collection of certificates. It is intended that
the set of certificates be sufficient to contain chains from a
recognized "root" or "top-level certification authority" to all of
the signers in the signerInfos field. There may be more
certificates than necessary, and there may be certificates
sufficient to contain chains from two or more independent top-
level certification authorities. There may also be fewer
certificates than necessary, if it is expected that recipients
have an alternate means of obtaining necessary certificates (e.g.,
from a previous set of certificates). The signer's certificate
MAY be included. As discussed above, if version 2 attribute
certificates are present, then the value of version MUST be 4.
While the use of version 1 attribute certificates is discouraged,
if version 1 attribute certificates are present and no version 2
attribute certificates are present, then the value of version MUST
be 3.
Looks fine.
11) Section 5.3, para "digestAlgorithm" See comment 7
above. Does the
should in the last sentence need to be SHOULD/MUST?
How about:
digestAlgorithm identifies the message digest algorithm, and any
associated parameters, used by the signer. The message digest is
computed on either the content being signed or the content
together with the signed attributes using the process described in
section 5.4. The message digest algorithm SHOULD be among those
listed in the digestAlgorithms field of the associated SignerData.
Implementations MAY fail to validate signatures that use a digest
algorithm that is not included in the SignedData digestAlgorithms
set.
fine.
14) Section 5.3, para "signature": I don't understand the
MUST in this
paragraph. The field is not optional how can it be omitted?
The MUST is
redundant.
I agree that the ASN.1 definition and this must statement are
redundant. They are not contradictory. What do you not
understand? What
change are you requesting?
I am requesting the removal of the MUST as there is no option. (Just to be
irritating, the field could be present but of zero length under the current
text.)
16) Section 5.3, para "attrValues": Append the following sentence.
"attrType may impose additional restrictions on the number
of items in the
set."
How about:
attrValues is a set of values that comprise the attribute. The
type of each value in the set can be determined uniquely by
attrType. The attrType MAY impose restrictions on the number of
items in the set.
I think this should be may not MAY as there is no protocol statement at this
point. If you want one then it should be "Signatures MUST fail verification
if any restrictions on the number of items in the set, imposed by an
attrType definition, are not met."
18) Section 6.1, para "version": What is the correct value
if v2 attribute
cert and unprotected attributes are present? Maybe should
change this to an
if - then - else type of writing.
It is pretty confusing. How about:
[*** NEW ***] version is the syntax version number. The
appropriate value depends on originatorInfo, RecipientInfo, and
unprotectedAttrs. The version MUST be assigned as follows:
IF (originatorInfo is present) OR (unprotectedAttrs
is present)
THEN
IF (any version 2 attribute certificates are present)
THEN version is 3
ELSE version is 2
ELSE
IF (any RecipientInfo structures are a version
other than 0)
THEN version is 2
ELSE version is 0
This is fine.
20) Section 6.1, para "certs": ditto above for some. What
is the "optional"
feature being discussed on the MAY.
How about:
certs is a collection of certificates. certs may contain
originator certificates associated with several different key
management algorithms. certs may also contain attribute
certificates associated with the originator. The certificates
contained in certs are intended to be sufficient for all
recipients to build certification paths from a recognized
"root" or "top-level certification authority." However, certs
may contain more certificates than necessary, and there may be
certificates sufficient to make certification paths from two or
more independent top-level certification authorities.
Alternatively, certs may contain fewer certificates than
necessary, if it is expected that recipients have an alternate
means of obtaining necessary certificates (e.g., from a
previous set of certificates).
Looks good.
21) Section 6.1, para "recipientInfos": Should change the ASN to
"RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo" to
reflect the MUST
in the text?
We use "SET OF" many places. I do not think we want to add
"SIZE (1..MAX)"
to them all. Therefore, I am not sure that there is any real
value in
adding it to this one.
This is the only one that I see where we have a requirement that the set
must not be empty and the element itself is not optional. In most all of
the other locations either the element itself can be omitted or the SET can
consist of 0 items.
23) Section 6.1, para "contentEncryptionAlgorithm": Please
explain the
MUST. How could you NOT use the same algorithm for each recipient?
Agree. How about:
The same content-encryption algorithm and content-encryption
key are used for all recipients.
fine.
25) Section 6.2.1, para "rid": Two items
a) do we want to change to text to allow for SKI's to be
non-certificate
based.
I see no reason to do this. Is there a constituency that needs it?
I was thinking of the PGP people, but don't have anything stronger. I don't
think we need to do this.
b) do we need a stronger definition of what a key transport
public key is
if there is a MUST for it being in the certificate.
[
Think about this
comment ]]]]]
I did think about your comment, and I do not think so. [[ I am
anticipating an embarrassing reply. ]] This field is within the key
transport recipient information, therefore any recipien
t
public key that is
used with this syntax (and is interoperable) must be a key
transport key.
The comment was for me, and I missed it in the review of the message. I
think I must have been wandering when I wrote this and I don't remember why.
Omit.
c) do we need to support both for specifying the
certificate or just for
locating a certificate? (i.e. encode vs decode)
We need both (for send and receive). I prefer the subject
key identifier;
it is smaller. However, S/MIME v2 requires issuer and serial
number, which
is bigger than a subject key identifier. If you do not think
that the MUST
statement is complete, please propose an alternative.
Alternative: "Implementations MUST support both alternatives for specifying
the recipient's certificate when decoding. Implementations MUST support one
of these alternatives for encoding."
27) Section 6.2.2, para "ukm": I believe this is a MUST not a SHOULD
statement. I understand that we don't require it for the
default algorithm
(ESDH), but it is premitted to occur. If UKM is not
supported then all that
could be done would be to ignore the recipient. (Note:
there is a MUST use
UKM in rfc2631 for one case.)
UKM is required for Static-Static Diffie-Hellman. I
basically agree with
your point, and it is not a big burden on an implementation.
However, I
would like to hear from more implementors before I make a change here.
John - please respond.
28) Section 6.3. Lets seperate the discussion on how to pad from the
content encryption process. I believe this should be moved
to the algorithm
section or a seperate section in this document. The CEK
algorithm is what
determines the padding method not CMS.
Not true. CMS encryption always uses this padding. CMS also
supports
algorithms that do not require any padding (for example, a
stream cipher),
but if padding is needed, this is the padding technique that
MUST be used.
I beg to differ with you on this issue. I believe that I could define a new
OID for RC5 with Ron's funky padding mode where the cipher text and plain
text are the same lengths. More importantly, with some of the new chaining
modes for AES where there is interleaving between mutiple chains, I can see
the padding to be done over a multiple of n blocks of data rather than one.
I repeat, the padding alogorithm is a fucntion of the specified encryption
algorithm and is not fixed.
29) Section 6.3, para 2: I don't like the section sentence in this
paragraph. The content begin encrypted has little or
nothing to do with the
value of the encrypted data octet string. This is the post
encryption
value.
I understand your point. These words have not changed in a very long
time. Perhaps you would like to propose some better ones.
Proposal: "The input to the content-encryption process is the "value" of
the content being enveloped. The resulting value of the encryption process
is then wrapped in an OCTET string for transporting."
33) Section 10.2.2: Why define another tag for v2 attribute
certificates.
We have never bothered with this for v1/v2/v3 certificates.
Long story. The short version is that v2 ACs are not
backward compatible
with v1 ACs. If you really want to hear the nasty, dirty details, I
suggest you talk to Hoyt or Sharron. This little jewel is
the reason that
the PKIX AC Profile requires the use of v2 ACs.
I can buy that. (Also it does justify uping the version number for me.)
36) Section 11.1: Content-type MUST be omitted when building counter
signatures.
Elsewhere the document says: "The content-type attribute is
not required
when used as part of a countersignature unsigned attribute as
defined in
section 11.4." This does not say MUST NOT to me. It says MAY. Eh?
I agree that that is what it presently says. In practice I don't believe
that any has ever encoding in a content-type and I would like to codify that
practice.
37) Section 11.1: There MUST be exactly one instance of
AttributeValue
present. -- MUST NOT is not testable.
It says: "A content-type attribute MUST have a single
attribute value, even
though the syntax is defined as a SET OF AttributeValue.
There MUST NOT be
zero or multiple instances of AttributeValue present."
So, you agree with the first sentence. I think the second
sentence is a
restatement of the first. Does the second sentence help
anyone understand?
I don't believe that the second statement helps. I did miss the fact that
it is a restatement of the first.
43) Section 11.5: Item 1 in the values. Change to "... but
MUST NOT contain
a content-type attribute. (No content type has been defined for a
counter-signature.)"
I assume that this is a comment about section 11.4, there is
no section 11.5.
See response to comment 36. It seem to me that you are
interpreting "need
not" as "MUST NOT." What have other implementors done?
see comment above on 36.
Russ
jim