Jim:
Here are my responses. I have not included the comments where my previous
reply resolved your concerns.
Where appropriate, I have addressed John Pawling's comments at the same
time. I hope that this leads to quicker closure, not confusion is
subsequent replies to this message.
> >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.
Okay. I added "the" in the places that seems appropriate.
> >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.
This is may be a thorny issue, so I started a separate thread for it.
> >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.)
John Pawling said: I agree with Jim. Recommend the following replacement:
OLD: [*** NEW ***] This field MUST be present; however, the details of the
signature depend on the signature algorithm employed.
NEW: [*** NEW ***] The details of the signature depend on the signature
algorithm employed.
Okay, you guys have convinced me. I dropped the first portion of the
sentence. The text now says:
signature is the result of digital signature generation, using the
message digest and the signer's private key. [*** NEW ***] The
details of the signature depend on the signature algorithm
employed.
> >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."
Agree, the "MAY" should be "can".
I go not agree with the MUST statement that you suggest. To enforce this,
a recipient must know all possible OIDs and the restrictions associated
with them.
The text now reads (I provided a bit more surrounding text for context):
The fields of type SignedAttribute and UnsignedAttribute have the
following meanings:
attrType indicates the type of attribute. It is an object
identifier.
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 can impose restrictions on the number of
items in the set.
> >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.
John Pawling said: I agree with Jim's recommendation.
Jim makes a good point. I will add the "SIZE (1..MAX)" here.
> >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.
[Snip]
> >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."
John Pawling said: Recommend changing second sentence to: "Implementations
MUST support at least one of these alternatives for encoding.".
In an attempt to use the same terminology as the rest of the paragraph, I
prefer "recipient processing" to "decode" and "sender processing" to "encode."
How about:
rid specifies the recipient's certificate or key that was used by
the sender to protect the content-encryption key. The
RecipientIdentifier provides two alternatives for specifying the
recipient's certificate, and thereby the recipient's public key.
The recipient's certificate MUST contain a key transport public
key. The content-encryption key is encrypted with the recipient's
public key. The issuerAndSerialNumber alternative identifies the
recipient's certificate by the issuer's distinguished name and the
certificate serial number; the subjectKeyIdentifier identifies the
recipient's certificate by the X.509 subjectKeyIdentifier
extension value. [*** NEW ***] For recipient processing,
implementations MUST support both of these alternatives for
specifying the recipient's certificate; and for sender processing,
implementations MUST support one at least of these alternatives.
> >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.
John Pawling said: Recommend the following replacement:
OLD: [*** NEW ***] Implementations SHOULD support UKM
processing. Implementations that do not process UKMs MUST gracefully
handle the presence of UKMs.
NEW: [*** NEW ***] Implementations MUST support ASN.1 decoding a
KeyAgreeRecipientInfo SEQUENCE that includes a ukm field. Implementations
that do not fully support the processing of UKMs MUST gracefully handle the
presence of UKMs.
Thanks John. Again, in an attempt to use common terminology, I prefer
"recipient processing" to "decode." How about:
ukm is optional. With some key agreement algorithms, the sender
provides a User Keying Material (UKM) to ensure that a different
key is generated each time the same two parties generate a
pairwise key. [*** NEW ***] Implementations MUST support
recipient processing of a KeyAgreeRecipientInfo SEQUENCE that
includes a ukm field. Implementations that do not support key
agreement algorithms that make use of UKMs MUST gracefully handle
the presence of UKMs.
> >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.
You have not convinced me. The way that I read the RFC 2630 text, we are
saying that if padding is needed, then this one padding technique must be
used. If no padding is needed, as is the case if Triple-DES CFB8 is used,
then no padding is present. If one of the proposed AES modes that provide
integrity and confidentiality were employed, the value of k might not match
the AES block size, but padding is still needed.
Right now, if padding is needed, we have one and only one way to do it. I
want to preserve this feature. In my view, support for other padding
approaches will only lead to more ways to fail interoperability.
If you still feel strongly about this one, please start a separate thread
for the discussion.
> >29) Section 6.3, para 2: I don't like the second 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."
John Pawling said: I believe that this paragraph should be deleted because
it is redundant to the first paragraph in section 6.3.
There was one point in the second paragraph that I thought should be
preserved. I have merged the two paragraphs as follows:
The content-encryption key for the desired content-encryption
algorithm is randomly generated. The input to the content-encryption
process is the "value" of the content being enveloped. This input
data is padded as described below, then the padded data is encrypted
using the content-encryption key. The encryption operation maps an
arbitrary string of octets (the data) to another string of octets
(the ciphertext) under control of a content-encryption key. The
encrypted data is included in the envelopedData encryptedContentInfo
encryptedContent OCTET STRING.
Note: Nothing is marked as "[*** NEW ***]." I consider this change to be
completely editorial.
> >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.
John Pawling said: I agree with Jim. Recommend the following re-wording of
his proposal be added as the last sentence of the 1rst paragraph: "The
content-type attribute MUST be omitted when used as part of a
countersignature unsigned attribute as defined in section 11.4."
I changed the discussion of the content-type attribute in section 5.3 as
follows:
A content-type attribute having as its value the content type
of the EncapsulatedContentInfo value being signed. Section
11.1 defines the content-type attribute. [*** NEW ***]
However, the content-type attribute MUST NOT be used as part of
a countersignature unsigned attribute as defined in section
11.4.
I also changed section 11.4 to match:
[*** NEW ***] Countersignature values have the same meaning as
SignerInfo values for ordinary signatures, except that:
1. The signedAttributes field MUST NOT contain a content-type
attribute; there is no content type for countersignatures.
2. The signedAttributes field MUST contain a message-digest
attribute if it contains any other attributes.
3. The input to the message-digesting process is the contents
octets of the DER encoding of the signatureValue field of the
SignerInfo value with which the attribute is associated.
> >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.
Perhaps making it all one sentence will make it clear that there is only
one idea being expressed. I consider this an editorial change, and I did
not insert "[*** NEW ***]."
How about:
Even though the syntax is defined as a SET OF AttributeValue, a
content-type attribute MUST have a single attribute value; zero or
multiple instances of AttributeValue are not permitted.
> >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.
John Pawling said: Recommend the following
replacement:
OLD: 1. The signedAttributes field MUST contain a message-digest
attribute if it contains any other attributes, but need not
contain a content-type attribute, as there is no content type for
countersignatures.
NEW: 1. The signedAttributes field MUST contain a message-digest
attribute if it contains any other attributes.
2. The signedAttributes field MUST NOT contain a content-type
attribute, because there is no content type for countersignatures.
I composed the text in response to comment 36 before I read John's
proposal. My text and John's text are almost identical (except for order),
so I assume that the text that I proposed above is acceptable.
Russ