NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 22-Jan-98
Chair(s):
Russ Housley <housley@spyrus.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Security Area Advisor:
Jeffrey Schiller <jis@mit.edu>
Mailing Lists:
General Discussion:ietf-smime@imc.org
To Subscribe: ietf-smime-request@imc.org
Archive: http://www.imc.org/ietf-smime/
Description of Working Group:
The S/MIME Working Group will define MIME encapsulation of digitally signed and encrypted objects whose format is based on PKCS #7. [1] X.509 Certificates and CRLs as profiled by the existing PKIX Working Group will be used to support authentication and key management. The Working Group will base its work on the S/MIME version 2 specification (available from RSA Data Security), but the Working Group will be free to change any part of that specification. In particular, the Working Group will prepare a new document that allows algorithm independence, based on PKCS #7 1.5.
The message syntax specification, based on PKCS #7 version 1.5, will be expanded to allow additional key signature and key exchange algorithms. The message and certificate specifications will be revised to allow them to become standards. The optional security extensions document will specify protocols that allow for additional security features, such as signed message receipts.
The S/MIME Working Group will attempt to coordinate its efforts with the OpenPGP Working Group in areas where the work of the two groups overlap, particularly in specification of cryptographic algorithms and MIME structure.
[1] RSA Data Security publishes the PKCS Series of documents. RSA Data Security has permitted the IETF to publish them as Informational RFCs as well as to extend and enhance them.
Goals and Milestones:
Nov 97 |
|
Submit First draft of message syntax specification as an I-D. |
Nov 97 |
|
Submit First draft of S/MIME v3 message specification as an I-D. |
Nov 97 |
|
Submit First draft of S/MIME optional security extensions as an I-D. |
Nov 97 |
|
Submit First draft of S/MIME v3 certificate specification as an I-D |
Dec 97 |
|
WG Last Call on Message Syntax. |
Dec 97 |
|
WG Last Call on Certificate Specification. |
Dec 97 |
|
WG Last Call on Message specification. |
Jan 98 |
|
WG Last Call on Optional Security Extensions. |
Jan 98 |
|
Submit Message Syntax I-D to IESG for consideration as a Proposed Standard. |
Jan 98 |
|
Submit S/MIME v3 message specification I-D to IESG for consideration as a Proposed Standard. |
Jan 98 |
|
Submit S/MIME v3 certificate specification I-D to IESG for consideration as a Proposed Standard. |
Feb 98 |
|
Submit S/MIME optional security extensions I-D to IESG for consideration as a Proposed Standard. |
Internet-Drafts:
· Cryptographic Message Syntax
· Enhanced Security Services for S/MIME
· S/MIME Version 3 Message Specification
· S/MIME Version 3 Certificate Handling
· Certificate Request Syntax
No Request For Comments
Minutes of the S/MIME Mail Security (smime) Working Group
I. Introductions - Russ Housley
Russ stated that the S/MIME version 2 documents are now available as Informational RFCs. He reiterated that the IETF S/MIME WG charter is to develop the S/MIME version 3 documents. Russ reviewed the agenda. Nobody objected to the agenda.
II. CMS Draft Discussion - Russ Housley
Russ presented several briefing slides regarding the CMS open issues. He noted that Section 9, Authenticated-Data Content Type needs to be completed including specifying the strategy for calculating a MAC or HMAC value. He will coordinate the proposed text with the WG.
Russ proposed that the text regarding the contentHints attribute be moved from the ESS I-D to the CMS I-D. Nobody objected.
Russ stated that Section 12, Supported Algorithms is incomplete, but that the majority of the information will be straightforward to supply except for the key management (KM) algorithm section. Russ stated that he has been notified that one or more organization(s) have applied for patents that cover some variants of the Diffie-Hellman (D-H) algorithm specified in the X9.42 specification. The current CMS draft cites X9.42 as a reference for the mandatory-to-implement D-H algorithm variant. It is still unclear if the potential patents cover the X9.42 D-H variant intended for use with CMS. Russ proposed to create an I-D specifying the proposed variant of the X9.42 D-H algorithm. He will then distribute that I-D with the request that all organizations state if they have intellectual property that covers the I-D. If any organizations make any such claims, then the I-D will be modified so that it avoids the use of the intellectual property while still providing a strong KM algorithm. Nobody objected to Russ' plan.
Russ stated that there is no standard method of encrypting a 3DES key with another 3DES key. Russ proposed to develop an I-D that specifies a proposed 3DES wrapping algorithm. The I-D will then be widely distributed for review. If required, the I-D will be revised to incorporate comments. Nobody objected to Russ' plan.
III. MSG Draft Discussion - Paul Hoffman
Paul led the discussion of the following open issues listed in the S/MIME v3 Message Specification I-D:
1) Should the MSG I-D list the documents needed to implement the algorithms supporting S/MIME (X9.42, X9.57, etc). Paul recommended that the MSG I-D should refer to the CMS I-D that includes references to the required algorithm specifications. Nobody objected.
2) Regarding MSG I-D, Section 2.6.1, there is disagreement about the last two steps in deciding which encryption algorithm to use when creating an envelopedData. Paul recommended that the current sections 2.6.1.3 and 2.6.1.4 should be replaced with the following: "2.6.1.3 Rule 3: Unknown Capabilities, Unknown Version of S/MIME: If the sending agent has no knowledge of the encryption capabilities of the recipient and the sending agent has no knowledge of the version of S/MIME of the recipient, then the sending agent SHOULD use tripleDES because it is a stronger algorithm and is required by S/MIME v3. If the sending agent chooses not to use tripleDES in this step, it SHOULD use RC2/40." Nobody objected. Paul noted that if an S/MIME v3 agent is sending an envelopedData to a legacy S/MIME v2 agent, then RC2/40 SHOULD be used because the S/MIME v2 agent may not have implemented tripleDES.
A WG member noted that the default encryption algorithm should result in strong cryptography (i.e. use tripleDES whenever possible, rather than RC2/40) and that if RC2/40 is used, then the user should be explicitly notified of that fact.
3) Regarding Section 4.1, key lengths for non-RSA key pair generation language are needed. A WG member asked if the WG was going to specify a D-H "common group" of algorithm parameters. The WG agreed that this was a good idea, but the use of the S/MIME WG-defined D-H "common group" would be optional because some organizations may wish to use locally-defined D-H "common groups". Paul recommended that the MSG I-D should refer to the CMS I-D which covers this topic. Nobody objected.
4) smimeVersion capability: Paul proposed that the smimeVersion feature should be added to the SMIMECapabilities list. 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. Nobody objected.
Jim Schaad addressed the following MSG I-D issues in later briefings:
"Add a section for selecting the encrypting X.509 certificate for a particular recipient"
"SMIMEEncryptionKeyPreference - which key should a sender announce for this? Also, unambiguous identification of X.509 certificates should be here, too."
IV. CERT Draft Discussion - Paul Hoffman
Paul noted that the S/MIME WG, as a general rule, should defer to the PKIX WG regarding the rules for populating information in X.509 certificates and CRLs. This will alleviate interoperability problems that could occur if S/MIME levies special requirements regarding the contents of X.509 certificates that are above and beyond the generic PKIX requirements. Paul led the discussion of the following open issues listed in the S/MIME v3 Certificate Handling I-D:
1) Names for chaining: Paul proposed that the S/MIME CERT I-D should refer to the PKIX X.509 Certificate and CRL Profile I-D (PKIX I) for specifying the rules for chaining. Nobody objected.
2) Use of keyUsage encipherOnly and decipherOnly bits in conjunction with the use of KM X.509 certificates. John Pawling read the X.509 description of the keyUsage encipherOnly and decipherOnly bits. He stated that he believes that their use is not clearly defined when a public key is to be used to form a pairwise key to encrypt or decrypt data. John proposed the following: "If the keyUsage keyAgreement bit is set to 1 AND if the public key is to be used to form a pairwise key to decrypt data, then the S/MIME agent MUST only use the public key if the keyUsage encipherOnly bit is set to 0. If the keyUsage keyAgreement bit is set to 1 AND if the key is to be used to form a pairwise key to encrypt data, then the S/MIME agent MUST only use the public key if the keyUsage decipherOnly bit is set to 0." This issue will be further discussed on the S/MIME mail list.
3) Do we need to further qualify the syntax for rfc822Name (no wildcards or comments)? Paul proposed that the S/MIME CERT I-D should refer to PKIX I regarding this issue. Nobody objected.
4) Attribute Certificates: Paul noted that it is an action item for the PKIX WG to define the use of ACs. David Solo proposed that all references to ACs should be deleted from all of the S/MIME specifications until the syntax and use of ACs are well defined. Russ and John Pawling made the point that X.509 defines the AC syntax. However, Paul and Dave strongly believed that ACs should be deleted from the S/MIME specs since their use is not defined and the PKIX AC syntax may be changed. Nobody objected to this proposal. The details of this change will be discussed further on the.
5) S/MIME List: A WG member stated that he is concerned about the S/MIME specs relying on the PKIX specs which are still I-Ds. Jeff Schiller stated that the S/MIME WG needs to clearly state their dependencies on the PKIX WG to put pressure on them to finalize the PKIX I spec. Similarly, other IETF WGs are dependent on the S/MIME WG finalizing the S/MIME v3 specs. Paul volunteered to compile a list of S/MIME dependencies on the PKIX I spec.
V. Authenticated Originator Certificate - John Pawling
John recommended adoption of Jim Schaad's original proposal to add a signing-certificate authenticatedAttribute to the CMS I-D as follows:
"11.5 Signing Certificate Attribute. The signing-certificate attribute type specifies the exact certificate used to sign the signed-data. This provides for an authenticated method of linking the certificate used to create the signed-data object and the signed-data object itself. If this attribute is not used and two different certificates are used for the same keys, it is possible to substitute the certificates without breaking the signature. It is suggested that the signing-certificate attribute be present if there are any authenticated attributes present. The signing-certificate attribute MAY be critical. The signing-certificate attribute MUST be authenticated. Only one instance of the signing-certificate attribute may appear in an attribute set. The following object identifier identifies the signing-certificate attribute: id-signingCert OBJECT IDENTIFIER ::= <TBD>. Signing-certificate attribute value has the ASN.1 type IssuerAndSerialNumber."
John presented slides explaining the process by which the originator composes a signedData object that includes a signing-certificate attribute and the process by which the recipient validates the signer's certification path and the signature of the signedData. The point of the briefing was that the combination of the IssuerAndSerialNumber info, certification path validation and verification of the signer's signature of the signedData object provides sufficient information to reliably identify the signer's X.509 certificate. John recommended that the IssuerAndSerialNumber syntax is appropriate for use for the signing-certificate attribute. He recommended that the subjectAltName and a hash of the X.509 certificate should not be included in the signing-certificate syntax. Denis Pinkas presented a briefing in which he proposed that issuerAltName and certificateHash should be added as optional fields to the signing-certificate syntax. Denis' briefing slides provide more details.
Dave Solo stated that he did not believe that the signing-certificate attribute is needed to unambiguously identify the signer's identity. He believes that the content of the signedData should include enough semantic information to unambiguously identify the signer (if that is desired) rather than relying solely on the information in the signer's X.509 certificate.
Russ asked for a show of hands regarding who believed that the IssuerAndSerialNumber syntax should be sufficient to unambiguously identify the signer. He also asked who believed that the signing-certificate attribute should include information (such as the subjectAltName and certificate hash value) in addition to IssuerAndSerialNumber. Twice as many hands were raised for the second option as for the first.
In a later discussion, this issue was raised again and Russ explained the issue. Russ asked who believed that the signing-certificate attribute should be added to the S/MIME specs. The vote was 6 to 7 in a room filled with several hundred people. It was apparent from this vote and from the discussion of the WG members that there was not a consensus regarding the purpose and syntax of the signing-certificate attribute, so the result of the earlier straw poll was overturned. This issue will be further discussed
on the S/MIME mail list.
VI. ESS Draft Discussion - Paul Hoffman
Paul led the discussion of the following open issues related to the ESS I-D:
1) Paul proposed that the text regarding the contentHints attribute be moved from the ESS I-D to the CMS I-D. Nobody objected.
2) Paul explained the proposal for the signature-purpose attribute and that it should be included in a separate document. Nobody objected.
3) Paul proposed that the group accept his recommended text for new wording regarding what to do if a signedData has multiple signerInfos, some of which don't have mlExpansionHistory attributes. Paul's e-mail message (Subject: RE: ESS-04 Comments, 24 Mar 98) to the list describes this proposal. Paul explained that his proposal allows gateways to add a signerInfo without an mlExpansionHistory attribute. Nobody objected.
4) John Pawling proposed that the ESSSecurityLabel security-policy-identifier should be changed from optional to mandatory. Nobody objected to John's proposal.
VII. E-Mail Address in Certificates - J.L. Cote
J.L. stated that the Canadian government wants e-mail addresses to be optional for inclusion in X.509 certificates. This was addressed in the last version of the CERT I-D. J.L. also stated that X.400 addresses should be documented in addition to RFC822 addresses. Nobody objected.
VIII. Signature and Key Management Certificates - Jim Schaad
Jim explained why separate signature and KM keys are required for a single end entity. He explained the problems associated with separate keys as keeping track of the different keys, making associations between the different keys, publishing the different keys and making it known which of a user's keys should be used for KM. He explained that there various methods of associating the different keys including subject name matching, alternate subject name matching and others. The MSG I-D, Section 2.5.3 documents the SMIMEEncryptionKeyPreference authenticatedAttribute. Jim proposed that the following process be documented in the MSG I-D:
· If an SMIMEEncryptionKeyPreference attribute is found in a signedData object, this identifies the X.509 certificate that should be associated as the KM X.509 certificate for the user.
· If an SMIMEEncryptionKeyPreference attribute is not found in a signedData object, the set of X.509 certificates should be searched for a X.509 certificate with the same subject name as the signing X.509 certificate which can be used for KM.
· Or use some other method of determining the user's KM key. If no KM X.509 certificate is found, then encryption cannot be done with the signer of the message. If multiple X.509 certificates are found, the S/MIME agent can make an arbitrary choice between them.
Jeff Schiller asked why the SMIMEEncryptionKeyPreference attributes is needed. Jim answered that it is required to facilitate the bootstrapping of an encryption exchange. A signer sends a signedData that includes the signer's KM X.509 certificate which the recipient can then use to send an envelopedData back to the signer.
A WG member asked if the user's KM X.509 certificate will be included in the signedData object. Jim answered that it should be included, but may be omitted if the sender knows that the recipient already has it.
Nobody objected to Jim's proposal.
IX. Certificate Distribution - Jim Schaad
Jim outlined the current strategies for publishing X.509 certificates: LDAP userCertificate; X.500 Directory entry; S/MIME signedData message; CMS certificate-only attachment; and other methods such as vCard. Jim said that the problems with these strategies is that they: do not carry a full certification path; can only carry a single KM X.509 certificate; and does not carry any S/MIME capabilities. Jim proposed that a new inner content type should be defined as id-ct-publish. This would indicate that the signedData: does not include a content; does include authenticatedAttributes (could include SMIMEEncryptionKeyPreference attribute); and may include multiple KM X.509 certificates. Jim proposed that the new content type could be signed by either an end-entity or X.509 certificate issuer. He also proposed the addition of a new LDAP userSMIMECertificate (binary) schema property.
John Pawling asked how the message digest value would be calculated if the content was absent. Jim answered that the digest would be calculated over the initialization value for the hash algorithm that is being used.
The WG decided that they should pursue Jim's proposals within the S/MIME WG. The WG also decided that Jim's proposal should be documented in a separate I-D.
X. Other Discussion
1) Paul Hoffman asked that people use meaningful names in their e-mail message subject lines when making new proposals or creating a new thread on the S/MIME mail list.
2) Russ stated that he believes that the ESS, CERT and MSG I-Ds will be ready for Working Group last call in April 98. He also stated that his goal is for the CMS I-D to be ready for Working Group last call in April 1998; however, the D-H patent issue and 3DES wrapping issue may delay the schedule. Since ESS, CERT, and MSG depend on CMS, they cannot go to IESG last call until CMS is ready to go to IESG last call as well.
3) Darren Harter stated that there is a problem if a BER-encoded authenticatedAttribute is received by an S/MIME agent that does not recognize the OID for the attribute. In this case, the receiving agent can't decode the attribute and re-encode it using DER because the agent does not know the syntax of the attribute. This may result in a signature verification error. Darren proposed the following options for solving this problem: mandate DER encoding of the complete signedData object; or change syntax of authenticatedAttribute to use OCTET STRING (similar to v3 X.509 certificate Extension format). Russ stated that his initial position is to mandate DER-encoding of the authenticatedAttributes. This solves the problem stated by Darren, because the receiving agent can simply hash over the transmitted DER-encoded authenticatedAttributes without decoding and re-encoding them. This issue will be resolved through messages on the S/MIME mail list.
SMIME - Agenda
Cryptographic Message Syntax
Certificate Unique Identifier
Publishing Certificates
SMIME Open Issues
Authenticating Originator's X.509 Certification Path