Subject: S/MIME WG Minutes from the 54th IETF

From: "Yee, Peter" <[email-masked]>
Date: Tue, 6 Aug 2002 11:30:51 -0700

The minutes for the S/MIME Working Group meeting at the Yokohama
IETF follow.  If you find any egregious mistakes, please let me
know.  None of the presenters have complained yet. :-)

Thanks.
						-Peter Yee
						[email-masked]

This message includes the official minutes of the IETF S/MIME Working
Group (WG) meeting held at the 54th IETF in July 2002 in 
Yokohama, Japan.  Briefing slides will be available from 
<ftp://ftp.ietf.org/ietf/smime/>.  Reported by Peter Yee.

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

Introductions:  Russ Housley covered the agenda for the meeting.
No changes from the floor were offered or made.

  Introductions                        Russ Housley
  Working Group Status                 Russ Housley
  CMSbis Status                        Russ Housley
  MSGbis Update                        Russ Housley for Blake Ramsdell
  CERTbis Update                       Russ Housley for Blake Ramsdell
  X400wrap and X400transport Update    Sean Turner for Chris Bonatti
  CMS and ESS Examples Update          Russ Housley for Paul Hoffman
  Interoperability Matrix Update       Jim Schaad
  AES Update                           Jim Schaad
  RSA-OAEP Update                      Russ Housley
  PGP Certificate Support              Derek Atkins
  Wrap up                              Russ Housley

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

Working Group Status:  Russ covered the current status of the active
documents in the working group.  Changes in status since the last
meeting are as follows.

Published as an RFC:
  - 3278 April 2002.  Use of Elliptic Curve Cryptography (ECC) Algorithms
         in Cryptographic Message Syntax (CMS).  S. Blake-Wilson,
         D. Brown, and P. Lambert.
  - 3114 May 2002.  Implementing Company Classification Policy with the
         S/MIME Security Label.  W. Nicholls.
  - 3274 June 2002.  Compressed Data Content Type for Cryptographic
         Message Syntax (CMS).  P. Gutmann.

RFC Editors Queue:
  - rfc2630bis  Cryptographic Message Syntax.  R. Housley
  - cmsalg      Cryptographic Message Syantx (CMS) Algorithms.
                    R. Housley
  - aes-keywrap AES Key Wrap Algorithm.  J. Schaad and R. Housley.

With the IESG for consideration:
  - x400wrap       Securing X.400 Content with S.MIME.  P. Hoffman,
                       C. Bonatti, and A. Eggen.
  - x400transport  Transporting S/MIME Objects in X.400.  P. Hoffman
                       and C. Bonnati.
  - symkeydist     CMS Symmetric Key Management and Distribution.
                       S. Turner.

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

CMSbis Status:  About to be published as a Proposed Standard.  Blocked
  from going to Draft Standard until RFC 3280 progresses to Draft
  Standard.

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

MSGbis Update:  Changes from -00:
  o Minor editorial work
  o Clarified "certificate managment" vs. "certs-only" (message
      content has not changed, only clarified).

Outstanding issues:
  o CompressedData use.  Which comes first sign or compress?  Should
      we expand SMIMECapabilities to indicate the compression algorithms
      that a recipient supports?  Current thinking is to add compression
      as a MAY.  Could be supported as a further profile of S/MIME or 
      could use the SMIMECapabilities (which many implementations only
      handle process in conjunction with encrypted messages).  Jim
      Schaad (Soaring Hawk) does not want compression for signed-only
      messages.  Further, Jim believes that compression should be applied
      after signing.  That is, the SignedData should be compressed.
  o Header field protection.  Would like to protect the RFC 2822 headers.
      To do so, the full 822 messsage is wrapped and protected in S/MIME.
      Then, outer headers for the S/MIME message are added that suffice
      for message delivery.
  o Inner binary encoding?  Triple-wrapped messages have considerable
     expansion due to Base-64 encoding for each layer of encapsulation.
     Is it acceptable only to Base-64 encode the outermost wrapper?
     S/MIME v2 used Base-64 encoding at each encapsulation because some
     older clients could not handle a binary transfer encoding type.  If
     we use binary encoding for inner wrappers, there is a problem with
     some gateways that remove security layers, exposing the contents 
     (such as DOMSEC).  If the exposed MIME type is multipart, then the
     re-encoding could impact signature validation.  The use of binary
     encoding is simply to reduce message expansion.  How the inner
     binary encoding is used can be done by two ways, it can be done as
     a profile, or it can be communicated through SMIMEcapabilities.
     Jim Schaad pointed out that RFC 2633 currently requires support for
     binary encoding.  Tim Polk (NIST) argued that it might cause
     interoperability problems, regardless of what the RFC decrees.  Many
     implementations handle inner binary encoding.  All implementers that
     responded to a S/MIME working group mailing list survey that was 
     conducted several months ago indicated that their code could handle
     binary encoding.  Further, no one expressed concerns in this area.

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

CERTbis Update:
  o  Must not used v1 Attribute Certificates -- PKIX already mandates v2.
  o  MD2 security warning -- should not be used, but there are a few roots
       that use RSA-MD2
  o  Minor editorial work

Close to last call, so please get your inputs to Blake Ramsdell (Brute Squad
Labs) or Russ Housley (RSA Labs), via the mailing list.

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

X400wrap & X400transport Update: X.400 Wrap is analgous to the MSG document,
and X.400 transport tells how to carry CMS objects via X.400 MTAs.

The documents are with the IESG, and the IETF Chair has raised a few
questions.  These questions are answered in new versions that are out to
the co-authors.  They should be posted soon.

One major issue:
  o  Header field protection
     Solutions:
     -  Encapsulate the message (including headers) in message/rfc822 and
        protect that
     -  Agree upon rules for merging inner/outer headers (inner protected
        and 822 headers must match!)
     -  Indicator to signal header merging needed

Documents are moving down the Standards Track, not Informational.  The -05
drafts will be released by the authors, hopefully getting these documents
closer to moving on.

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

CMS and ESS Examples Update: New examples for inclusion in the document
have been sent to Paul Hoffman.  As soon as they are incorporated, a new
version of the document will be posted.  All implementers are asked to 
confirm that the examples produce the expected output.

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

Interoperability Matrix Update: Needs to be updated for rfc2630bis
and cmsalg (which are in the RFC Editor's Queue).

No recent implementer updates to the CMS information.  The CMS 
Algorithms portion of the matrix is very close (HMAC/SHA-1 is 
outstanding).

The SignedData portion has 6 items to go, and the EnvelopedData
portion has 10 items to go.

Paul Hoffman (IMC) has offered to coordinate interoperability testing

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

AES Update: Separated the AES and OAEP drafts.  The AES Keywrap is in
the RFC Editor's Queue.  One open issue remains in the AES for CMS
draft.  The mailing list constituency seems to want to allow RSA PKCS#1
v1.5 to wrap an AES key.  Jim Schaad does not want to allow this pairing.
Options:
 o  Keep MUST NOT (disallow this pairing)
 o  Change MUST NOT to MAY (with author's comment against doing the MAY)
 o  CHANGE to MAY and update SMIMECapabilities to allow for pairing
    information

Those present felt that MUST NOT was preferred, but the mailing list will
be polled again for a final input.  The draft will be posted at the end
of the week, and once this one decision is made, the document will be
ready for working group last call.

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

RSAES-OAEP Update: Separated from the merged AES-OAEP document.  Other
separate but somewhat related documents are AES for CMS, RSA-KEM key
transport, and RSA-PSS digital signature.  The current (-03) draft of
RSAES-OAEP was posted June 2002.  Russ went over the structure of the
new draft.  A couple of questions were raised:

 o Is it okay to use the same RSA public/private key for RSAES-OAEP
   and other things.
   -- Not suggested.
 o Is RSAES-OAEP with SHA-1 secure for key transport of AES keys?
   -- SHA-1 used with 1024-bit RSA public key provides the equivalent of
      80-bit symmetric key, with respect to signatures.  This comparison
      is not so straightforward for key transport.  However, Burt Kaliski
      and others feel that the signature relationship is a low watermark
      for key transport, so for AES key transport, SHA-1 is not suggested.
      Thus, SHA-256, SHA-384, and SHA-512 will be added to ASN.1 module
      and suggested for use, but leave SHA-1 as the MUST implement.  Also,
      the updated draft will require RSA keys to be at least 1024 bits.

Working group last call, with the additions suggested above, would come
in August 2002.

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

PGP Certificate Support: Derek Atkins (IHTFP Labs) suggested that with
many PGP Certificates out there and many S/MIME clients, the combination
of the two might be useful.  Essentially, this would be a binding of
PGP keys to be used in S/MIME messages (the converse is being worked in
the PGP working group).

In a straw poll, only one person thought that the support for PGP
certificates should not be investigated.  Many others thought that
an internet-draft should be developed.

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