Here are my responses, where an item is omitted you can assume that I agree
with your resolution.
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
However as I look at the abstract for draft -00, the second
"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.
I will need to read what you did. I was actully asking for "the" to be
omitted. I think that "The CMS" is incorrect.
16) Section 5.3, para "attrValues": Append the
"attrType may impose additional restrictions on the
number of items in the
attrValues is a set of values that comprise 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
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
a recipient must know all possible OIDs and the restrictions
The text now reads (I provided a bit more surrounding text
The fields of type SignedAttribute and UnsignedAttribute have the
attrType indicates the type of attribute. It is an object
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
items in the set.
Can we add the statement about failing verification to the attributes that
we have defined where it make sense? I think that if there are two
content-type or two message-digest attributes that the verification process
really needs to fail. I am more unsure what should be done for other
attributes as you are correct that an exhaustive set would be required to
verify. Let me think about this issue.
25) Section 6.2.1, para "rid": Two items
a) do we want to change to text to allow for SKI's to be
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:
MUST support at least one of these alternatives for encoding.".
In an attempt to use the same terminology as the rest of the
prefer "recipient processing" to "decode" and "sender
processing" to "encode."
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
recipient's certificate, and thereby the recipient's
The recipient's certificate MUST contain a key transport public
key. The content-encryption key is encrypted with the
public key. The issuerAndSerialNumber alternative
recipient's certificate by the issuer's distinguished
name and the
certificate serial number; the subjectKeyIdentifier
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
implementations MUST support one at least of these
I would have liked to allow for SKI to be used in a non-certificate
environment, but I don't have any problems with the updated text.
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
(ESDH), but it is premitted to occur. If UKM is not
could be done would be to ignore the recipient. (Note:
there is a
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
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.
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,
provides a User Keying Material (UKM) to ensure that a
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
the presence of UKMs.
I agree with the update.
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
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
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
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
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
for the discussion.
You have not convinced me, but I will think about this.
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
value of the encrypted data octet string. This is the
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
is then wrapped in an OCTET string for transporting."
John Pawling said: I believe that this paragraph should be
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
process is the "value" of the content being enveloped. This input
data is padded as described below, then the padded data
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
encryptedContent OCTET STRING.
Note: Nothing is marked as "[*** NEW ***]." I consider this
change to be
I don't like the text "This input data is padded as described below, ...".
However as this relates to my comment #28, I will think about this before
37) Section 11.1: There MUST be exactly one instance of
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
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 ***]."
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.
I find this much clearer