Russ,
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
objecting.
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.
I find this much clearer
Russ
jim