John:
Thanks for the comments. Here are my responses.
1) Sec 2, last sent: Please delete "Since the signed-data content type
requires DER encoding, an extra pass may be necessary when a content type
other than data is encapsulated." According to CMS Sec 5.3, DER encoding of
the content is not always required.
Agree. I will replace the sentence; it may be a good idea to point out that
authenticated attributes are DER encoded. How about, "Authenticated
attributes
within the signed-data content type require DER encoding."
2) Sec 5.1, next to last para, last 2 sents: Please make the following
change because EncapsulatedContentInfo is not optional (the eContent field
within EncapsulatedContentInfo is optional):
Old: "If the EncapsulatedContentInfo value is absent, the signatureValue is
calculated as though the EncapsulatedContentInfo value was present. The
presumed EncapsulatedContentInfo must have the content type set to id-data
(as defined in section 4) and the content omitted."
New: "If the EncapsulatedContentInfo eContent value is absent, the
signatureValue is calculated as though the eContent value was present. The
EncapsulatedContentInfo must have the eContentType set to id-data (as
defined in section 4) and the eContent field omitted."
Good catch. How about the following as a replacement for that paragraph:
The optional omission of the eContent within the EncapsulatedContentInfo field
makes it possible to construct "external signatures." In the case of external
signatures, the content being signed is absent from the
EncapsulatedContentInfo
value included in the signed-data content type. If the eContent value within
EncapsulatedContentInfo is absent, then the signatureValue is calculated as
though the eContent value was present, the eContentType value within
EncapsulatedContentInfo must be set to id-data (as defined in section 4), and
the eContent field omitted.
3) Sec 5.2 and App A: Recommend that SignerInfo
unauthenticatedAttributes>should be defined as "Attributes" instead of
"CMSAttributes" since CMS
prohibits unauthenticatedAttributes from being marked as critical, so the
critical flag can never be used in this case. The CMS ASN.1 module can
import Attributes and Attribute from X.501.
One group has already tried to define some private authenticated attributes.
Since we imported the structure from X.501, they used the macros defined there
for their definition. This made the job much harder since they include
irrelevant information like matching rules.
I replaced CMSAttributes with two types: AuthAttributes and UnauthAttributes:
AuthAttributes ::= SET OF AuthAttribute
AuthAttribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
attrValues SET OF AttributeValue }
UnauthAttributes ::= SET OF UnauthAttribute
UnauthAttribute ::= SEQUENCE {
authAttrType OBJECT IDENTIFIER,
authAttrValues SET OF AttributeValue }
AttributeValue ::= ANY
Does this resolve your concern?
4) Sec 5.3, 1rst para, 3rd sent: Please make the following change to clarify
the text:
old: "Specifically, the initial input is the content OCTET STRING of the
content field of the EncapsulatedContentInfo value to which the signing
process is applied. Only the contents of the OCTET STRING are input to the
message digest algorithm, not the identifier octets or the length octets."
new: "Specifically, the initial input is the encapContentInfo eContent OCTET
STRING to which the signing process is applied. Only the octets composing
the value of the eContent OCTET STRING are input to the message digest
algorithm, not the OCTET STRING tag and length octets."
Good clarification. I did a small amount of word smithing:
Specifically, the initial input is the encapContentInfo eContent OCTET STRING
to which the signing process is applied. Only the octets comprising the value
of the eContent OCTET STRING are input to the message digest algorithm, not
the
tag or the length octets.
5) Sec 5.3, 3rd para: Please make the following change because the
data>content type is no longer a special case. This text applies to all
content
types:
old: "When the content being signed has a content type of data (as defined
in section 4) and the authenticatedAttributes field is absent, then just the
value of the data (e.g., the contents of a file) is input to the message
digest calculation."
new: "When the authenticatedAttributes field is absent, then only the octets
composing the value of the signedData encapContentInfo eContent OCTET STRING
(e.g., the contents of a file) are input to the message digest calculation."
Agree.
6) Sec 5.3, 4th para: Please make the following change to clarify the text:
old: "Although the identifier octets and the length octets are not included
in the message digest calculation,.."
new: "Although the encapContentInfo eContent OCTET STRING tag and length
octets are not included in the message digest calculation,..."
Agree.
7) Sec 6.3, first 3 paras: IMHO, the first 3 paragraphs of Sec 6.3 should
be replaced with: "The content-encryption key for the desired
content-encryption algorithm is generated at random. The data to be
protected is padded as described below. The padded data is then 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."
These are the paragraphs that I believe should be deleted because I believe
that they are obsolete and are not required for S/MIME v2 backwards
compatibility:
"The input to the content-encryption process is the "value" of the
content being enveloped. Only the content octets; identifier or
length octets are not included.
When the content being enveloped has content type of data (as defined
in section 4), then just the value of the data (e.g., the contents of
a file) is encrypted. This has the advantage that the length of the
content being encrypted need not be known in advance of the
encryption process.
The identifier octets and the length octets are not encrypted. The
length octets may be protected implicitly by the encryption process,
depending on the encryption algorithm. The identifier octets are not
protected at all, although they can be recovered from the content
type, assuming that the content type uniquely determines the
identifier octets. Explicit protection of the identifier and length
octets requires that the signed-data content type be employed prior
to digital enveloping."
I do like your lead in paragraph. However, the fact that the tag and length
octets are not encrypted needs to be preserved. How about:
The content-encryption key for the desired content-encryption algorithm is
randomly generated. The data to be protected 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.
The input to the content-encryption process is the "value" of the content
being
enveloped. Only the content octets are encrypted; the tag and the length
octets are not included. The length octets may be protected implicitly by the
encryption process, depending on the encryption algorithm. The tag octets are
not protected at all, although they can be recovered from the content type,
assuming that the content type uniquely determines the identifier octets.
Explicit protection of the identifier and length octets requires that the
signed-data content type be employed prior to digital enveloping.
8) Sec 9 and App A: Recommend adding authenticatedAttributes to
the>AuthenticatedData SEQUENCE. I believe that the signingTime and
essSecurityLabel authenticatedAttributes would be useful. If
authenticatedAttributes are present, then the MAC value could be calculated
on the concatenation of the content (value octets of the encapContentInfo
eContent OCTET STRING) and DER encoded authenticatedAttributes. The
messageDigest attribute would not be used.
Agree. I will work with Rich Ankney to come up with an acceptable syntax.
9) Sec 11.2: Please make the following change to be consistent with the
signedData encapContentInfo change:
old: "The message-digest attribute type specifies the message digest of the
contents octets of the DER encoding of the content field of the ContentInfo
value being signed in signed-data, where the message digest is computed
using the signer's message digest algorithm."
new: "The message-digest attribute type specifies the message digest of the
encapContentInfo eContent OCTET STRING being signed in signed-data (see
Section 5.3), where the message digest is computed using the signer's
message digest algorithm."
Agree.
10) App A: Import "Attribute" and "Attributes" from X.501 so they can be
used for signedData signerInfo unauthenticatedAttributes.
Disagree. See proposed AuthAttrinutes and UnauthAttributes above.
11) The following proposals were made at an informal meeting held in San
Francisco on 14 Jan 98 to discuss S/MIME-related issues, but are not
included in CMS-03:
"One issue discussed was the process by which an agent
determines which of a remote user's certificates should be used for KM
purposes to support the encryption of a CMS EnvelopedData object. It is
proposed that a new authenticated attribute will be defined in CMS that will
identify which of a user's X.509 certificates (usually communicated in the
SignedData certificates field) is to be used for key management purposes.
For example, User 1 sends a SignedData object including his KM and DS
Certificates in the SignedData certificates field and the authenticated
attribute indicating which of the certs is his KM cert. The remote user
would then know which cert to use for KM purposes when sending an
envelopedData object to User 1. (Note that the EnvelopedData recipientInfo
originatorCert field is used to indicate which of the originator's certs (if
required by the KM algorithm (such as D-H)) is to be used for KM purposes to
support the decryption of an envelopedData object.)
The following rule is also proposed for addition to CMS: "If
the new authenticated attribute is absent, then the signature and KM
certificates must include the same subject identifying information
(i.e., subject DN and/or subjectAltName)." If the new attribute is
absent, then the sending agent would examine the OID in the
subjectPublicKeyInfo field of each cert to determine if the OID indicates
the purpose (ex: id-dsa indicates that a DSS key is included in the cert).
The agent MUST also examine the keyUsage extension, if present, to
determine the intended usage of the public key included in the cert."
Sorry, I do not have this in my notes. Please start a thread on the mail list
to come to concensus on the ASN.1 syntax for the new attribute.
Again, thanks of the speedy and thorough review,
Russ