All,
I have the following comments to the Jan 98 CMS-03 I-D:
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.
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."
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.
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."
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."
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,..."
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."
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.
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."
10) App A: Import "Attribute" and "Attributes" from X.501 so they can be
used for signedData signerInfo unauthenticatedAttributes.
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."
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================