Subject: 3/17/99 S/MIME WG Mtg Minutes

From: [email-masked] (John Pawling)
Date: Fri, 26 Mar 1999 18:01:23 -0500

All,

This message includes the minutes of the IETF S/MIME Working Group 
(WG) meeting held on 17 March 1999 in Minneapolis, MN, USA. These 
minutes were coordinated with the briefing presenters.  All briefing 
slides are stored at: ftp://ftp.ietf.org/ietf/smime/.  Reported by
John Pawling.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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:
   1.  Compute a 20 octet SHA-1 message digest on the CEK.
   2.  Use the most significant (first) eight octets of the message 
       digest value as the checksum value.

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:
   1.  Set odd parity for each of the DES key octets comprising the 
       CEK, call the result CEK.
   2.  Compute an 8 octet key checksum value on CEK as described 
       above, call the result ICV.
   3.  Let CEKICV = CEK || ICV.
   4.  Generate 8 octets at random, call the result IV.
   5.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use 
       the random value generated in the previous step as the 
       initialization vector (IV).  Call the ciphertext TEMP1.
   6.  Let TEMP2 = IV || TEMP1.
   7.  Reverse the order of the octets in TEMP2.  That is, the most 
       significant (first) octet is swapped with the least significant 
       (last) octet, and so on.  Call the result TEMP3.
   8.  Encrypt TEMP3 in CBC mode using the key-encryption key.  Use IV 
       of 0x4adda22c79e82105.  The ciphertext is 40 octets long.

The Triple-DES key unwrap algorithm decrypts a Triple-DES CEK using a 
Triple-DES KEK.  The CMS-11 DES key unwrap algorithm is:
   1.  If the wrapped CEK is not 40 octets, then error.
   2.  Decrypt the wrapped CEK in CBC mode using the KEK.  Use an IV 
       of 0x4adda22c79e82105.  Call the output TEMP3.
   3.  Reverse the order of the octets in TEMP3.  That is, the most 
       significant (first) octet is swapped with the least significant 
       (last) octet, and so on.  Call the result TEMP2.
   4.  Decompose the TEMP2 into IV and TEMP1.  IV is the most 
       significant (first) 8 octets, and TEMP1 is the least 
       significant (last) 32 octets.
   5.  Decrypt TEMP1 in CBC mode using the key-encryption key.  Use     
       the IV value from the previous step as the initialization 
       vector.  Call the ciphertext CEKICV.
   6.  Decompose the CEKICV into CEK and ICV. CEK is the most 
       significant (first) 24 octets, and ICV is the least significant 
       (last) 8 octets.
   7.  Compute an 8 octet key checksum value on CEK as described 
       above.  If the computed key checksum value does not match the 
       decrypted key checksum value, ICV, then error.
   8.  Check for odd parity each of the DES key octets comprising CEK.  
       If parity is incorrect, then there is an error.

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 asked if there were any other unresolved issued regarding CMS. 
Denis Pinkas stated that he believes that CMS should specify how key 
validation is performed.  He is especially concerned with the case in 
which multiple Certification Authority (CA) certificates contain the 
same public key. 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 and that CMS 
should not replicate that information.  

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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 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 RFC2459 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 [email-masked].

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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).

=========================================================
John Pawling,  Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
[email-masked]
=========================================================