Current Meeting Report
2.5.8 S/MIME Mail Security (smime)
NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It
may now be out-of-date. Last Modified:
Russ Housley <firstname.lastname@example.org>
Security Area Director(s):
Jeffrey Schiller <email@example.com>
Marcus Leech <firstname.lastname@example.org>
Security Area Advisor:
Jeffrey Schiller <email@example.com>
To Subscribe: firstname.lastname@example.org
Description of Working Group:
The S/MIME Working Group has completed five Proposed Standards that
comprise the S/MIME version 3 specification. Current efforts build
on these base specifications.
The use of Diffie-Hellman Key Agreement as the mandatory to implement
key establishment mechanism may expose some implementations to
vulnerabilities based on "small subgroup" attacks. An informational
document will be prepared describing techniques that can be used to
avoid these attacks.
The Cryptographic Message Syntax (CMS) is cryptographic algorithm
independent, yet there is always more than one way to use any
To ensure interoperability, each algorithm should have a specification
that describes its use with CMS. Specifications for the use of
additional cryptographic algorithms will be developed. An additional
suite of 'mandatory to implement' algorithms may be selected.
To aid implementers, documents containing example output for CMS will
be collected and published. Some of the examples will include
structures and signed attributed defined in the Enhanced Security
Services (ESS) document.
Current methods of publishing certificates in the Directory do not
allow the inclusion of secondary support information such as the
SMimeCapabilities attribute. A method of publishing certificates
along with authenticated secondary support information will be
In some situations it would be advantageous for the CMS RecipientInfo
structure to support additional key management techniques, including
cryptographic keys derived from passwords. A mechanism to facilitate
the definition of additional key management techniques will be defined.
S/MIME version 3 permits the use of previously distributed symmetric
key-encryption keys. Specifications for the distribution of
symmetric key-encryption keys to mmultiple message recipients will
be developed. Mail List Agents (MLAs) are one user of symmetric
key-encryption keys. The specification will be cryptographic
S/MIME version 3 supports security labels. Specifications that show
how this feature can be used to implement an organizational security
policy will be developed. Security policies from large organizations
will be used as examples.
S/MIME version 3 can be used to protect electronic mail to and from a
domain. In such an environment, S/MIME v3 processing is performed by
message transfer agents, guards, and gateways in order to provide
"Domain Security Services." Mechanisms are needed to solve a number of
interoperability problems and technical limitations that arise when
domains supporting different security policies wish to interoperate.
The S/MIME Working Group will attempt to coordinate its efforts with
OpenPGP Working Group in areas where the work of the two groups
Goals and Milestones:
|Done||  || First draft of CMS RecipientInfo extension.|
|Done||  || First draft of security label usage specification.|
|Done||  || Last call on small subgroup attack avoidance|
|Done||  || First draft of CAST algorithm specification.|
|Done||  || Last call on KEA and SKIPJACK algorithm specification.|
|Done||  || First draft of mail list key distribution.|
|Done||  || Last call on certificate distribution specification.|
|Done||  || Updated draft of domain security services document.|
|Done||  || Last call on CAST algorithm specification.|
|Done||  || Submit small subgroup attack avoidance as Informational RFC|
|Done||  || Submit KEA and SKIPJACK algorithm specification as Informational RFC.|
|Done||  || Last call on security label usage specification.|
|Dec 99||  || Last call on CMS and ESS examples document.|
|Done||  || Last call on IDEA algorithm specification.|
|Done||  || Last call on CMS RecipientInfo extension.|
|Jan 00||  || Last call on mail list key distribution.|
|Jan 00||  || Submit certificate distribution specification to IESG for consideration as a Proposed Standard.|
|Feb 00||  || Submit security label usage specification as Informational RFC.|
|Done||  || Submit CAST algorithm specification as Informational RFC.|
|Mar 00||  || Submit CMS and ESS examples document as Informational RFC.|
|Mar 00||  || Submit CMS RecipientInfo extension to IESG for consideration as a Proposed Standard.|
|Mar 00||  || Submit mail list key distribution to IESG for consideration as a Proposed Standard.|
|Done||  || Submit IDEA algorithm specification as Informational RFC.|
|Done||  || Last call on domain security services document.|
|Sep 00||  || Submit domain security services as Experimental RFC.|
Request For Comments:
|RFC2311|| ||S/MIME Version 2 Message Specification
|RFC2312|| ||S/MIME Version 2 Certificate Handling
|RFC2630||PS||Cryptographic Message Syntax
|RFC2631||PS||Diffie-Hellman Key Agreement Method
|RFC2632||PS||S/MIME Version 3 Certificate Handling
|RFC2633||PS||S/MIME Version 3 Message Specification
|RFC2634||PS||Enhanced Security Services for S/MIME
|RFC2785|| ||Methods for Avoiding the 'Small-Subgroup' Attacks on
the Diffie-Hellman Key Agreement Method for S/MIME
|RFC2876|| ||Use of the KEA and SKIPJACK Algorithms in CMS
|RFC2984||PS||Use of the CAST-128 Encryption Algorithm in CMS
|RFC3058|| ||Use of the IDEA Encryption Algorithm in CMS
|RFC3125||E ||Electronic Signature Policies
|RFC3183||E ||Domain Security Services using S/MIME
|RFC3126|| ||Electronic Signature Formats for long term electronic
|RFC3185||PS||Reuse of CMS Content Encryption Keys
Current Meeting Report
This message includes the official minutes of the IETF S/MIME Working Group (WG) meeting held at the 52nd IETF in December 2001 in Salt Lake City, UT, USA. Briefing slides will be available from
<ftp://ftp.ietf.org/ietf/smime/>. Reported by Jim Schaad.
Introductions: Russ Housley covered the agenda for the meeting. No changes were made.
Introductions Russ Housley
Working Group Status Russ Housley
CMS Update Status Russ Housley
Interoperability Matrix Jim Schaad
CMS and ESS Examples Paul Hoffman
AES and RSA-OAEP Jim Schaad
Symmetric Key Distribution Sean Turner
Intended Recipient Attribute R. Housley & J. Schaad
Policy Requirements for TSAs Denis Pinkas
Signature Delegation Denis Pinkas
Wrap up Russ Housley
Working Group Status and CMS Update Status: Russ covered the current status of the active documents in the working group. Current statuses are:
- Password, Triple-DES/RC2 Key Wrap, and Preventing the Million Message Attack on CMS documents are in RFC Editor 48 hour review.
- Security Label Implementation document is on hold by request of working group chairman, and hold will be released when the Attribute Certificate Profile is published.
- Compression, ECC, X400 Wrap, X400 Transport, and Symmetric Key Distribution drafts are currently with the IESG.
- RFC2630bis and CMSAlg are in IETF Last Call.
New versions of these RFC 2632 and RFC 2633 are needed since RFC2630bis has removed algorithm requirements. Blake Ramsdell, the editor of these documents, has recently changed jobs so a delay in updating the documents is expected. The updated documents will reflect the mandatory to implement algorithm requirements that were previously debated and accepted:
Signature Verification: DSA and RSA (PKCS#1 v1.5)
Signature Generation: DSA or RSA (PKCS#1 v1.5)
One-way Hash Function: SHA-1
Key Management: RSA (PKCS#1 v1.5)
Encryption: Triple-DES CBC
Interoperability Matrix: Jim Schaad presented a briefing on the current state of interoperability testing for the RFC2630bis and CMSAlg drafts. In the core of the two documents SignedData has 6 items left, EnvelopedData has 10 items left, SigningTime has 2 items left and HMAC-SHA-1 has 3 items left.
Jim also presented two issues that had arisen during interoperability testing:
The first issue dealt with the problem of wrapping an HMAC key with a
Triple-DES, RC2 or AES key. Currently, one password-based key management includes a defined method for this operation. A new draft is to be prepared to define a mechanism.
The second issue dealt with DER encoding of SignedAttributes within the SignerInfo structure. Three alternatives were presented for a straw poll: 1) SignedAttributes must be DER encoded, 2) Attribute must be DER encoded, 3) AttributeValue must be DER encoded. Option 1 was the unanimous selection of the voters.
CMS/ESS Examples: Paul Hoffman discussed this document (without slides). He is ready to request that the working group chair make a last call for the document to be published as an Informational RFC. There is an expectation that an update to the document will be produced in the future to deal with omissions from the current document and new examples that employ the AES algorithm.
AES/RSA-OAEP: Jim Schaad presented the current status of the AES/RSA-OAEP draft. AES became FIPS 198 on 16 November 2001. Additionally the AES key wrap candidate algorithm was released in November. As this is still a draft document, and NIST has not produced a document that can be referenced. An informational track document covering the AES key wrap algorithm will be produced by the working group. The authors believe that the AES/RSA-OAEP draft should be ready for working group last call before the next IETF meeting.
Symmetric Key Distribution: Sean Turner gave a presentation on the status of this draft. He has received a few comments, even though the document has already passed working group last call. One set was editorial, and the other was a request for an additional attribute dealing with security policy. The latter request will probably be handled as a separate Internet-Draft to avoid delaying the symmetric key distribution draft. So far, an author has not volunteered.
Intended Recipient Attribute: Don Davis (from Curl Corp.) has identified a potential problem. The concern is that a recipient of signed and encrypted message can decrypt the message, preserving the original signature, and then resend the message to a new recipient. New recipient may act inappropriately based on the fact that they received a message signed by the original originator, not the middleman (for further discussion see draft-ietf-smime-sender-auth-00.txt). Russ Housley has prepared a potential solution to this problem (see draft-ietf-smime-ira-00.txt).
Russ presented the problem and his solution to the group, including the benefits and some potential drawbacks. Jim Schaad then presented a second view of the problems, attempting to resolve the issue in an Email environment. In the discussion that followed Phillip Hallam-Baker raised the point that while this solution covered the question of the TO and CC header lines, it did nothing to solve the problem of preventing the leakage of the SUBJECT line in a message. Following the discussion two straw polls were taken.
- Should the sender-auth draft be progressed as an information draft? The vote was unanimously no.
- Should the ira draft be progressed, and if so, on what track? The vote was unanimously for non-progression of this document as well.
Russ Housley took an action item to bring the question of general protection of the headers to the mail list.
Policy Requirements for TSAs: Denis Pinkas presented the status of the ETSI document on this topic. The final version of the document has not been published yet, but the current document is available at http://portal.etsi.org/sec/STF178Task1FinalDraft.pdf.
Signature Delegation: Denis Pinkas then presented some thoughts on a mechanism for a person to delegate their signature authority. A possible mechanism using the id-aa-ets-signerAttr was presented. Comments on whether the problem should be addressed by the working group and possible solutions will be discussed further on the mail list.
Wrap Up: Russ Housley asked if there were any other issues to discuss.
No additional issues were raised, and the working group meeting was adjourned.
Working Group Status
Intended Recipients Attribute
Cryptographic Message Syntax (CMS) Status
Policy requirements for Time-Stamping Authorities
CMS Interop Matrix
S/MIME Symmetric Key Distribution