All,
First, I want to thank Blake for incorporating my previous comments into the
March 11, 1998, S/MIME V3 Message Specification. I have some new comments
as follows. I have also taken the liberty to include comments submitted by
others that I believe have achieved WG consensus, but were not included in
MSG-02. Recommend that everybody should look at this list to ensure that
they agree with the comments and that I did not omit a comment:
1) Sec 2.1, 1rst sent: Please replace "Receiving agents MUST support SHA-1
[SHA1]." with "Sending and receiving agents MUST support SHA-1 [SHA1]."
2) Sec 2.4.1: Please make the following change:
OLD: "Sending agents MUST use the "data" content type as the content within
other content types to indicate the message content which has had security
services applied to it."
NEW: "Sending agents MUST use the id-data content type identifier to
indicate the message content which has had security services applied to it.
For example, when applying a digital signature to MIME data, the CMS
signedData encapContentInfo eContentType MUST include the id-data object
identifier and the MIME content MUST be stored in the SignedData
encapContentInfo eContent OCTET STRING. As another example, when applying
encryption to MIME data, the CMS EnvelopedData encryptedContentInfo
ContentType MUST include the id-data object identifier and the encrypted
MIME content MUST be stored in the envelopedData encryptedContentInfo
encryptedContent OCTET STRING."
3) Sec 2.5, para 3: Jim Schaad commented:
"Section 2.5 paragraph 3. Encryption Key Preference is not an attribute
that is needed by all senders of S/MIME messages. I suggest we change this
to: "Sending agents SHOULD be able to generate one instance of each of the
signed attributes described in this section, and SHOULD include the signing
time and SMIMEcapabilities attributes in each signed message sent."
4) Sec 2.5.1: Please make the following change:
OLD: "Agents MUST interpret the year field (YY) as follows:"
NEW: "When the UTCTime CHOICE is used, agents MUST interpret the year field
(YY) as follows:"
5) Sec 2.5.2: Jim Schaad commented (There was debate regarding this comment,
but I don't remember the answer. Russ, I believe that you had the answer.
Can you please provide it.)
"Section 2.5.2 This is a politics question and one I am not capable of
deciding. Do we need to change from using the IMC as the registration agent
for the OIDs of SMIMECapabilites? I don't see any techincal reasons to
change this at this point in time. I don't see IMC as disappearing any time
soon and from what I hear it would be much faster to get updates than using
IANA. But I don't know if the IESG will be willing to leave this as it is."
6) Sec 2.5.2: Jim Schaad commented:
"Section 2.5.2 I guess this is really an issue for Paul as the owner of the
SMIMECapabilites list. I hearby request that a new capability be added to
the list called "smimeVersions". This will have a content of a single
integer which will contain the version number of the highest S/MIME
specification understandable by the client. I hearby designate [SMIMEV2] to
have the number 2 and this draft to have the number 3. This will allow for
sending MUAs to be able to prevent sending critical attributes to clients
which will not understand them. This will also address any new
incompatabilies placed in the S/MIME specifications at a later time."
7) Sec 2.6, first para, every sent: Paul Hoffman wrote:
"Related to this, the paragraph at the beginning of 2.6 should have "Sending
and receiving..." at the beginning of each of the sentences. The "Receiving"
only is an artifact from our wigglywaggling in S/MIME v2."
8) Sec 2.6.1, last para: Please replace "2.6.2.1 through 2.6.2.4" with
"2.6.1.1 through 2.6.1.4" and re-number the sections accordingly.
9) Section 2.6.2.3 and 2.6.2.4: Jim Schaad commented:
"Section 2.6.2.3 and 2.6.2.4. The wording no longer works for these two
sections now that 3DES is a must and RC2/40 is an optional. I have switched
the order of the rules as tripleDES is now a MUST algorithm and is therefore
by definition supported, but we know that not everyone does support it. I
suggest that these sections be re-written as follows:
"2.6.1.3 Rule 3: Low Encryption Interopt Mode
If:
- the sending agent has no knowledge of the encryption
capabilities of the recipient,
- and the sending agent has reason to believe that the
recipient does not support high level encryption,
then the sending agent SHOULD use RC2/40.
2.6.1.4 Rule 4: Unknown Capabilities
If:
- the sending agent has no knowledge of the encryption
capabilities of the recipient, then the sending agent MUST
use tripleDES."
10) Section 2.6.4: Jim Schaad commented:
"Insert a new section 2.6.4 with the following text.
"Section 2.6.4 Selecting a Recipients Encryption Certificate
The use of the MUST algorithms in this specification lead to the problem of
given a user's signing certificate from a signed message, how is the
encryption certificate determined. Since the signing and key exchange
algorithms will no longer use the same certificates.
Section 2.5 defines a method by which a sending agent can optionally
announce what its perfered key-exchange certificate is. The following
method for processing and remembering the encryption certificate attribute
in incoming signed messages SHOULD be used.
If an Encryption Key preference attribute is found in a message, this is the
certificate that should be associated as the encryption certificate for the
user.
If no Encrytion Key preference attribute is found in a message, the set of
certificates should be searched for a certificate with the same DN as the
signing certificate which can be used for encryption. If no certificate is
found, then encryption cannot be done with the signer of the message. If
multiple certificates are found, the MUA can make an arbitrary choice
between them.
- If the receiving agent has not yet done an association for the sender's
encryption certificate, then, after verifiying the signature on the incoming
message and checking the timestamp, the receiving agent SHOULD create a new
associaiton containing the signing time and the encryption certificate.
- If such an association already exists, the receiving agent SHOULD verify
that the signing time in the incoming message is greater than the signing
time stored in the association and that the signature is valid. If so, the
receiving agent SHOULD update both the signing time and the encryption
certificate association. Values of the signing time that lie far in the
future (that is, a greater discrepancy than any reasonable clock skew), or
an encryption preference in a message whos signature cannot be verified,
MUST NOT be accepted."
11) Sec 3, first para: Please replace "PKCS" with "CMS".
12) Sec 3, first para: Please add as last sentences: "The Enhanced Security
Services for S/MIME [ESS] document provides examples of how nested, secured
S/MIME messages are formatted. For example, there is an example of how a
triple-wrapped S/MIME message is formatted using multipart/signed and
application/pkcs7-mime for the signatures."
13) Sec 3.2, 2nd para: Please make the following change:
OLD: "The contentInfo field of the carried CMS object always contains a MIME
entity that is prepared as described in section 3.1. The contentInfo field
must never be empty."
NEW: "The carried CMS object always contains a MIME entity that is prepared
as described in section 3.1. Also, see Section 2.4.1 for instructions on
including the id-data OID and MIME entity in the CMS objects."
14) Sec 3.4, first sent: Please change "application/pkcs7-mime and
SignedData" to "application/pkcs7-mime with SignedData" in the following:
"There are two formats for signed messages defined for S/MIME:
application/pkcs7-mime and SignedData, and multipart/signed.:
15) Sec 3.4.2, title: Please change "application/pkcs7-mime and SignedData"
to "application/pkcs7-mime with SignedData" in the following: "3.4.2 Signing
Using application/pkcs7-mime and SignedData"
16) Sec 3.4.2: Please change "application/pkcs7-mime and SignedData" to
"application/pkcs7-mime with SignedData" in the following: "The smime-type
parameter for messages using application/pkcs7-mime and SignedData is
"signed-data"."
17) Sec 3.4.3, last sent: Please make the following change:
OLD: "The first part contains the MIME entity that is to be signed; the
second part contains the signature, which is a CMS detached signature."
NEW: "The first part contains the MIME entity that is signed; the second
part contains the "detached signature" CMS SignedData object in which the
encapContentInfo eContent field is absent."
18) Sec 3.4.3, 2nd sent: Please replace "PKCS" with "CMS" in the following:
"This format is a clear-signing format. Recipients without any S/MIME or
PKCS processing facilities are able to view the message."
19) Sec 3.4.3.1, 2nd sent: Please make the following change:
OLD: "The contentInfo field of the CMS object must be empty."
NEW: "The signedData encapContentInfo eContent field MUST be absent."
20) Sec 3.4.3.2, Step 2: Please make the following change:
OLD: "Step 2. The MIME entity is presented to CMS processing in order to
obtain an object of type signedData with an empty contentInfo field."
NEW: "Step 2. The MIME entity is presented to CMS processing in order to
obtain an object of type signedData in which the encapContentInfo eContent
field is absent."
21) Sec 3.4.3.2, Step 4: Please make the following change:
OLD: "Step 4. Transfer encoding is applied to the detached signature and it
is inserted into a MIME entity of type application/pkcs7-signature"
NEW: "Step 4. Transfer encoding is applied to the "detached signature" CMS
SignedData object and it is inserted into a MIME entity of type
application/pkcs7-signature"
22) Section 3.4.3.2, paragraph 8: Jim Schaad commented:
"Section 3.4.3.2, paragraph 8. micalg can contain a list of values.
Suggest the paragraph be re-worded as follows:
"The micalg paramter allows for one-pass processing when the signature is
being verified. The value of the micalg parameter is dependent on the
message digest algorithm(s) used in the calculation of the Message Integrity
Check. If multiple message digest algorithms are used they should be
seperated by commas. The values to be placed int eh micalg parameter SHOULD
be from the following:"
23) Sec 3.6, Step 1, last para: Please make the following change:
OLD: "The contentInfo and signerInfos fields must be empty."
NEW: "The signedData encapContentInfo eContent field MUST be absent and
signerInfos field MUST be empty."
24) Sec 3.7, last para, last sent: Please delete: "S/MIME v2 specified a
non-standard technology for certificate management."
25) Sec 4, 1rst para, last sent:
OLD: "S/MIME certification issues are covered in a different document."
NEW: "S/MIME certification issues are covered in the "S/MIME Version 3
Certificate Handling [CERT3]" document."
26) App A: Jim Schaad proposed:
"Appendix A. I would like to update the ASN for
SMIMEEncryptionKeyPreference as follows:
SMIMEEncryptionKeyPreference ::= CHOICE {
issuerAndSerialNumber IMPLICIT [0] IssuerAndSerialNumber,
receipentKeyId IMPLICIT [1] RecipientKeyIdentifier,
subjectAltKeyIdentifier IMPLICIT [2] KeyIdentifier,
sha1Hash IMPLICIT [3] OCTET STRING
}
On the inclusion of a certificate identifier in the signed data object,
several people have asked to be able to use a hash as this is generally much
smaller than an issuerAndSerialNumber, thus I have included it here first."
27) App B, Please add: "[CERT3] "S/MIME Version 3 Certificate Handling",
Internet Draft, draft-ietf-smime-cert-*.txt."
28) App B, Please add: "[ESS] "Enhanced Security Services for S/MIME",
Internet draft, draft-ietf-smime-ess-*.txt."
29) App B, CMS reference: Please make the following change:
OLD: "[CMS] "Cryptographic Message Syntax", Internet Draft
draft-housley-smime-cms"
NEW: "[CMS] "Cryptographic Message Syntax", Internet Draft,
draft-ietf-smime-cms-*.txt."
30) App D: Recommend deleting Appendix D because it is out of date and is
not needed, IMHO.
31) App F.1, 3rd para, next to last sent: Please change "PKCS7-object" to
"CMS object".
32) App H. Needed changes #1: "We need to document Diffie-Hellman parameters
(key lengths, etc.) -- is this a separate draft?" This is provided in CMS,
so this bullet should be deleted.
33) App H. Needed changes #2: "Section A cleanup (SMIMECapabilities and
SMIMEEncryptionKeyPreference in their own sections?)" Leave as is and
delete this bullet.
34) App H. Needed changes #3: "Should SMIMEEncryptionKeyPreference simply be
IssuerAndSerialNumber?" See Jim Schaad's proposed change. If accepted,
delete this bullet.
35) App H. Needed changes #4: "ASN.1 issues -- syntax, CCITT vs. ITU-T in
section 1.3, OID cleanup" Jim Schaad wrote: "NEW: Need to get an OID for
SMIMEEncryptionKeyPreference and smimeVersions." Recommend deleting this
bullet.
36) App H. Needed changes #5: "Section 1.1 -- what documents are needed to
implement S/MIME. Should probably include X9.42, X9.57, etc." These are
provided in CMS, so this bullet should be deleted.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================