1. A general question for the list to look at. In S/MIME V2 we used
id-data as the ContentType oid to say the contents are MIME, there is
general conses that this was a mistake. The question is can this be
remedied at this point in time? Ways that this could be dealt with is to
say that id-data should continue to be used for SignedData version 1 objects
and EncryptedData version 0 objects, but a new oid should be used in other
cases. This would allow future versions of S/MIME to cut away from this old
method and put id-data back to its original intent, some arbitrary data is
here. What is the feelings of the list on this issue? My personal feeling
is that in an ideal world I would recommend doing this, however in reality I
think it would be a mistake because of the potential for error.
2. 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."
3. 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.
4. 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.
5. Section 2.6.2.1 Two issues. First the numbering is incorrect. It
should be section 2.6.1.1. Secondly capabilitie is misspelt in the 4th
paragraph.
6. 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 is 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."
7. Insert a new section 2.6.4 with the following text.
"Section 2.6.4 Selecting a receipients 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 deifnes 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 perference 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."
8. 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:"
9. Section 3.7. We are no longer in the game of doing PKI work. I
recommend we delete this entire paragraph. If people feel strongly that
something is needed then we should replace with a reference to SMIMEV2,
however I would argue that even this is not needed. If this goes then
Appendix E.3 should also go.
10. Appendix C. Delete the entire section. This should not be of any
importance now we are on standards track. (I may be too agressive on this
one.)
11. 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.
12. Open issues from Appendix H.
Need OIDs for Diffie-Hellman -- This should no longer be true, we get the
D-H oids from the CMS draft.
What do we need to do for 4.1 in order to make it Diffie-Hellman? -- Remove
the entire section. At most we should put in a paragraph about recommended
key lengths and nothing more about generation.
Cert generation in section 4.1 needs to talk about CMP from PKIX. --- No
we don't we should never talk about key generation.
Section 4.1 needs to talk about DSS and DH minimum key lengths for strong
crypto --- Yes -- see above comments.
Is [DSS] the correct reference? ---- Sorry I can't help you here. Copy the
reference from CMS when it gets one.
Algorithm identifiers need more cleanup --- I don't understand this issue
beyond the addtion of SMIMEEncrytionKeyPreference. Yes the ones duplicated
in CMS could be removed, but I don't see any real urgency on this.l
Section A cleanup (SMIMECapabilities and SMIMEEncryptionKeyPreference in
their own sections?) --- Why bother.
Should SMIMEEncryptionKeyPreference simply be IssuerAndSerialNumber? --- No
see above recommended change.
ASN.1 issues -- syntax, CCITT vs. ITU-T in section 1.3 --- I can't help you
here, except to say as we are now in the IETF rather than being an
independent spec, I see no problems with just deleting this section out of
hand.
NEW:
Need to get an OID for SMIMEEncryptionKeyPreference
Need to get an OID for smimeVersions.