2.6.5 S/MIME Mail Security (smime)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 06-Jan-99

Chair(s):

Russ Housley <housley@spyrus.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortel.ca>

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 Certifiticate 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:

Request For Comments:

RFC

Status

Title

 

RFC2311

 

S/MIME Version 2 Message Specification

RFC2312

 

S/MIME Version 2 Certificate Handling

Current Meeting Report

Introductions - Russ Housley

Russ reviewed the agenda. Nobody objected to the agenda.

CMS Draft Discussion - Russ Housley

Russ presented the status of the February 1999 Cryptographic Message Syntax (CMS-11) Internet-Draft (I-D). CMS-11 is in IETF Last Call. The majority of the comments received since the last meeting have focused on Section 12. (This is the section on algorithms and key wrapping support.) CMS-11 includes new key wrap algorithms that resolve the issues raised on the S/MIME WG mail list regarding possible cryptographic vulnerabilities such as Burt Kaliski's comments regarding the "birthday attack". The completion of CMS depends on the Diffie-Hellman (D-H) Key Agreement Method I-D (X9.42 I-D).

Russ reviewed the highlights of the CMS-11 Key Wrapping Algorithm sections. CMS-11 documents a mandatory-to-implement key wrapping algorithm that describes the process of wrapping a Triple-DES content encryption key (CEK) with a Triple-DES key encryption key (KEK). It documents another (optional) key wrapping algorithm that describes the process of wrapping an RC2 CEK with an RC2 KEK. Each key wrapping algorithm includes instructions for key checksum, key wrap and key
unwrap.

The CMS-11 Checksum Algorithm is used to provide a CEK integrity check value. The algorithm is:

The Triple-DES key wrap algorithm encrypts a Triple-DES CEK with a Triple-DES KEK. The CMS-11 Triple-DES key wrap algorithm is:

The Triple-DES key unwrap algorithm decrypts a Triple-DES CEK using a Triple-DES KEK. The CMS-11 DES key unwrap algorithm is:

Jim Schaad sent comments to the mail list regarding the CMS-11 RC2 Key Wrap Algorithm. Russ briefed the following RC2 Key Wrap algorithm that includes Jim's comments:

1. Let LCEKPAD = LENGTH || CEK || RANDOM_PAD.
2. Compute checksum on LCEKPAD, call result ICV.
3. Let LCEKPADICV = CEK || ICV.
4. Generate 8 octets at random, call the result IV.
5. Encrypt LCEKPADICV in CBC mode using above IV. Call ciphertext TEMP1.
6. Let TEMP2 = IV || TEMP1.
7. Let TEMP3 = REVERSE(TEMP2)
8. Encrypt TEMP3 in CBC mode using IV of 0x4adda22c79e82105.

Russ briefed the following RC2 Key Wrap algorithm that includes Jim's
comments:

1. If the wrapped key length is not a multiple of 8, then error.
2. Decrypt wrapped key in CBC mode using IV of 0x4adda22c79e82105. Call the output TEMP3.
3. TEMP2 = REVERSE(TEMP3)
4. Decompose the TEMP2 into IV and TEMP1.
5. Decrypt TEMP1 in CBC mode using IV from above. Call the ciphertext LCEKPADICV.
6. Decompose the LCEKPADICV into LCEKPAD and ICV.
7. Validate ICV.
8. Decompose the LCEKPAD into LENGTH, CEK and PAD.

Russ stated that he believes that Jim's proposed changes should be incorporated into CMS. Nobody objected to the inclusion of Jim's proposals into CMS.

Way Forward: A new CMS draft (CMS-12) will include the harmonized Triple-DES and RC2 key wrap algorithms as stated above. CMS-12 will be posted as soon as the repository opens for the submission of new IETF drafts. CMS-12 is ready for discussion by the IESG when the X9.42 draft is completed.

Russ stated that Denis Pinkas submitted comments to the S/MIME WG mail list requesting additional text in CMS to explain how the correct signer's public key used to perform signature verification is obtained. Russ stated that he would work with Denis to derive the exact words to be proposed for addition to CMS and then the S/MIME WG members would be given the opportunity to review the proposed changes.

X9.42 Draft Discussion - Eric Rescorla

Eric discussed the status of the January 1999 D-H Key Agreement Method I-D (a.k.a. X9.42 I-D). One change to be made is that the actual RC2 key length will be the same as the effective key length. Eric stated that he believes that this change resolves the RC2 partition attack.

Eric also stated that Section 2.1.2, "Generation of Keying Material", will be changed to state that the KeySpecificInfo algorithm field will include the key wrap algorithm object identifier (OID) instead of the symmetric algorithm OID. The examples will be enhanced to match this change.

Nobody objected to Eric's proposed changes.

Small Subgroup Attacks on D-H Robert Zuccherato

Robert is developing an informational draft that will describe situations that require protection from "small subgroup" attacks on D-H. The draft will also provide guidance on how to provide protection.

When is protection required? In general, for sender:

1) If key is ephemeral, then no protection is required.
2) If key is static, protection is required.

In general, for a recipient (assuming static key):

1) If no information on the success of the decryption is available, no protection is required.
2) If information on the success of the decryption is available, protection is required.

Methods of Protection:
1) The process by which the recipient's public key is validated by the originator is described in the X9.42 draft. This strategy is possibly encumbered. Certicom has applied for a patent covering the use of methods to avoid small subgroup attacks.
2) Public key validation by the Certification Authority (CA) is only realistic for static public keys.
3) Choose p-1=2*q*r where r is product of "large" primes. Must still check whether public key is +/- 1.
4) Compatible Cofactor Exponentiation is described in IEEE P1363. Also possibly encumbered.

Russ stated that the purpose of this document is to inform people of when they need to worry about small subgroup attacks. Certicom has notified the S/MIME WG that they have a pending patent regarding small subgroup attack protection. If implementers need to be concerned with small subgroup attack protection, then they may wish to watch for this patent.

Eric Rescorla asked about the status of Certicom's offer for a royalty-free license that would allow S/MIME vendors to use the technology covered by their pending patent. Russ stated that Certicom had not yet offered any royalty-free licenses because they do not believe that their pending patent covers any mandatory S/MIME requirements. Russ also stated that this issue is still being worked.

MSG Draft Discussion - Blake Ramsdell

Blake stated that the 26 February 1999 S/MIME v3 Message Specification (MSG-07) I-D addresses the comments submitted to the mail list. Blake stated that the MSG I-D has been submitted for IETF last call. Blake asked if anybody knew of any unresolved issued regarding MSG.

Paul Hoffman proposed that the following statement should be added to Sec 2.2: "Note that S/MIME v2 clients are only capable of verifying digital signatures using the rsaEncryption algorithm." Paul also proposed that the following statement should be added to Sec 2.3: "Note that S/MIME v2 clients are only capable of decrypting content encryption keys using the rsaEncryption algorithm." Nobody objected to these changes.

CERT Draft Discussion - Blake Ramsdell

Blake stated that the 26 February 1999 S/MIME v3 Certificate Handling (CERT-07) I-D addresses the comments submitted to the mail list. Blake stated that the CERT I-D has been submitted for IETF last call.

Blake asked if anybody knew of any unresolved issued regarding CERT. Denis Pinkas stated that he believed that CERT should be changed to state that a receiving agent "MUST support revocation" rather than "MUST support CRLs". He said that his recommended wording would allow receiving agents to use other methods of revocation checking such as OCSP. Eric Rescorla made the point that the CMS heading includes fields to carry CRLs, so the receiving agent must use them. After several other attendees stated their opinions regarding the use of CRLs, Russ asked that the debate be put on hold until the end of the meeting so that the rest of the topics could be covered.

Denis has a second comment that he believed that the possible absence of the subject DN in a leaf certificate could present a problem. A vast majority of the meeting attendees decided that the PKIX X.509 Certificate and CRL Profile (RFC2459) (referred to by the CERT I-D) specifies how key validation is performed using certificates that may omit the subject DN and that CMS should not replicate that information.

Paul Hoffman pointed out that section 3 in CERT-07 needed to be modified to delete the "3.1" sub-section title.

ESS Draft Discussion - Paul Hoffman

Paul stated that the 26 February 1999 Enhanced Security Services for SMIME (ESS-11) I-D addresses the comments submitted to the mail list. It has been submitted for IETF last call.

Paul said that he will incorporate Francois Rousseau's comments sent to the mail list regarding the use of the signingCertificate attribute.

CERTDIST Draft Discussion - Jim Schaad

Jim stated that the 25 February 1999 Certificate Distribution (CERTDIST-03) I-D has not been significantly changed since the December 98 S/MIME WG meeting. He said that he still needs to include example data in the document. The next draft will be submitted for S/MIME WG last call after the example data has been added.

DOMSEC Draft Discussion - Bill Ottaway

Bill stated that the 17 November 1999 Domain Security Services using S/MIME (DOMSEC-01) I-D has been submitted to the mail list. He stated that there has been no changes to the domsec draft since the December 98 S/MIME WG meeting. He is currently working on an implementation of domsec. He intends to have a new draft, based on comments received and experience gained, before the current draft expires in May 99.

Security Policies and Labels Russ Housley

Russ stated that Weston Nicolls is developing an Internet draft that will document the security policies of Whirlpool, Caterpillar and Amoco. The draft will also document how the ESSSecurityLabel can be used to implement those corporations' security policies. Russ stated that the S/MIME WG Charter will be expanded to cover this work. Nobody objected.

S/MIME v3 Examples Paul Hoffman

Paul stated that the 25 February 1999 Examples of CMS Message Bodies (EXAMPLES-00) I-D has been submitted to the mail list. Paul stated that the document will include example keys, certificates and CRLs. The next draft will include CRLs. The document will include some incorrect examples that flag common implementation errors. Paul is only going to coordinate putting this document together. He needs example data for the document and he needs people to volunteer to test the sample data. Volunteers will be given credit in the document. Individuals would like to volunteer to do examples should contact Paul at phoffman@imc.org.

Wrap Up - Russ Housley

Russ stated that the CMS, ESS, MSG, CERT and X9.42 documents are in IETF Last Call. He hopes to have these documents reviewed by the IESG as soon as possible.

John Pawling asked if there was a strategy for enhancing the S/MIME v3 documents after they are approved by the IESG. Russ stated that minor changes could be made in the documents when they progress from Proposed Standard to Draft Standard. For example, the proposed change to the CMS RecipientInfo syntax could be made when CMS progresses from Proposed Standard to Draft Standard, if consensus is reached on the handling of password-based key management.

Open Issues

The debate resumed regarding Denis Pinkas' proposal to change CERT so that it states that a receiving agent "MUST support revocation" rather than "MUST support CRLs". After much exciting debate, the majority of the group reached consensus that CERT sections 2.1 and 4.1 must be changed to state the following: "All agents MUST be capable of performing revocation checks using CRLs as specified in RFC2459. All agents MUST perform revocation status checking in accordance with RFC2459."

ACTION ITEMS (These changes will be included in the S/MIME v3 documents after they have been discussed on the S/MIME WG mail list):

1. Enhance CMS I-D to include Jim's comments regarding the RC2 key wrapping and unwrapping algorithms (Russ Housley).
2. Enhance X9.42 I-D to include changes regarding RC2 key length and key wrap algorithm OIDs (Eric Rescorla).
3. Develop I-D regarding small subgroup attacks on D-H (Robert Zuccherato).
4. Enhance MSG I-D to include Paul's comments regarding S/MIME v2 agents to MSG draft (Blake Ramsdell).
5. Enhance CERT I-D sections 2.1 and 4.1 as described above (Blake Ramsdell).
6. Enhance ESS I-D to include Francois Rousseau's comments regarding signingCertificate attribute (Paul Hoffman).
7. Develop I-D regarding security policies and labels (Weston Nicolls).
8. Incorporate sample data into Example I-D (Paul Hoffman).

Slides

None received.