Subject: Re: Charter Modification

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 1 Sep 2004 21:18:04 +0200

Thanx Craig,
I was not aware of the mailsig (WG?) list.   That means this
is outside of the S/MIME charter I suppose?

BTW, here is a "competitor":
http://www.opengroup.org/comm/press/19jul04.htm

What I have seen little of, is how this can scale without having
a gateway PKI in place.  Peer-to-peer certification does not seem
like a terribly good idea.

Regards
Anders
----- Original Message -----
From: Craig McGregor
To: Anders Rundgren
Cc: Sean P. Turner ; SMIME
Sent: Tuesday, August 31, 2004 23:23
Subject: RE: Charter Modification

Anders,

I wasn't at the BOF you mentioned but as I understand it the BOF was scoped for signing/authenticating e-mail.
Draft Charter: http://www.imc.org/ietf-mailsig/mail-archive/msg00000.html
Minutes: http://www.imc.org/ietf-mailsig/mail-archive/msg00025.html

S/MIME gateways could use all existing S/MIME specifications and not be limited to only signing outbound e-mail. e.g. Encryption
over the untrusted networks that transports messages between domains that might otherwise have some level of trust.

I would also like to see an interoperable S/MIME Gateway||Domains||Entities standard or specification. I have had some past
experience at making a limited set of S/MIME gateway software talk to each other reliably. This was more challenging at that time
than it should have been.

S/MIME Gateway signing and encryption is quite possible in a closed-community of domains today - example: http://e.govt.nz/see/mail/
(Since November 2000)

If it was possible to solve key management, PKI trust and legacy interoperability (including mailing-list behaviour) using something
that scales to an open community then an S/MIME gateway approach could certainly work in the open community. Solving all three of
these problems isn't necessarily easy.

Regards,
Craig

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Anders Rundgren
Sent: Tuesday, 31 August 2004 6:09 p.m.
To: Sean P. Turner; SMIME
Subject: Re: Charter Modification

How about including a S/MIME gateway task?
The OpenGroup and Blake B are reportedly working on such a thing.

What happened with the gateway BOF that Phill H-B wrote about sometime ago?

An S/MIME gateway standard is really needed as S/MIME end-to-end encryption is not going anywhere.

Anders
----- Original Message -----
From: Sean P. Turner
To: SMIME
Sent: Tuesday, August 31, 2004 01:41
Subject: Charter Modification

All,

To include Stefan's work in the working group we need to modify the working group's charter (we also needed to update the dates
anyway because some are way off).  Attached is the proposed modification.  Please respond with any comments by  Friday.

Cheers,

spt

S/MIME Mail Security (smime)

Chair:
     Sean Turner <[email-masked]>
     Blake Ramsdell <[email-masked]>

Security Area Director:
     Russ Housley <[email-masked]>
     Steve Belovin <[email-masked]>

Security Area Advisor:
     Russ Housley <[email-masked]>

Mailing Lists:
     General Discussion: [email-masked]
     To Subscribe:       [email-masked]
     Archive:            http://www.imc.org/ietf-smime/

Description of Working Group:

The S/MIME Working Group has completed a series of Proposed Standards that comprise the S/MIME version 3.1 specification. As part of
the specification update, a new suite of "mandatory to implement" algorithms was be selected. Current efforts update and build upon
these base specifications.

The Cryptographic Message Syntax (CMS) (RFC 3852) is cryptographic algorithm independent, yet there is always more than one way to
use any algorithm. 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.

To aid implementers, documents containing example output for CMS will be collected and published. Some of the examples will include

structures and signed attributes defined in the Enhanced SecurityServices (ESS) (RFC 2634) document.

CMS, as well as S/MIME version 3 and later, permit the use of previously distributed symmetric key-encryption keys. Specifications
for the distribution of symmetric key-encryption keys to multiple message recipients will be developed. Mail List Agents (MLAs)
areone user of symmetric key-encryption keys. The specification will be algorithm independent.

To aid initial determination of recipient's cryptographic capabilities a specification will be developed allowing S/MIME
capabilities to be stored and asserted in X.509 certificates based on the X.509 certificate and CRL profile developed by the PKIX
Working Group.

The working group will perform necessary interoperability testing to rogress the CMS and S/MIME specifications to Draft Standard.
The CMS specification depends on the RFC 3280. This profile must progress to Draft Standard before CMS and the other S/MIME
specifications can progress to Draft Standard. Assuming timely progress by the PKIX Working Group, the S/MIME specification can
start progressing to Draft Standard in 2005.

Milestones:

History
     Submit CMS compressed data content type a Proposed Standard.
     Submit security label usage specification as Informational RFC.
     Submit elliptic curve algorithm specification as Informational RFC.
     Submit update to CMS as a Proposed Standard.
     Submit CMS Algorithms as a Proposed Standard.
     Submit AES key wrap algorithm description as Informational RFC.
     Last call on X.400 CMS wrapper specification.
     Last call on X.400 transport specification.
     Last call on HMAC key wrap description specification.
     Last call on RSA OAEP algorithm specification.
     Last call on AES algorithm specification.
     Last call on update to MSG.
     First draft of update to CERT.
     First draft of CMS and ESS examples document.
     First draft of S/MIME version 3.1 interoperability matrix.
     First draft of RSA PSS algorithm specification.
     Submit mail list key distribution as a Proposed Standard.
     Submit HMAC key wrap description as Proposed Standard.
     Submit RSA OAEP algorithm specification as a Proposed Standard.
     Sumbit AES algorithm specification as Proposed Standard.
     Submit X.400 CMS wrapper specification as a Proposed Standard.
     Submit X.400 transport as a Proposed Standard.
     Last call on CMS and ESS examples document.
     Sumbit update to CERT as Proposed Standard.
     Sumbit update to MSG as Proposed Standard.
     First draft of RSA KEM algorithm specification.
     Last call on RSA PSS algorithm specification.
     Submit RSA PSS algorithm specification as Proposed Standard

September 04
     Submit CMS and ESS examples document as Informational RFC
     First draft of S/MIME Capabilities Certificate Extension

October 04
     Working Group Last Call for S/MIME Capabilities Certificate Extension

December 04
     Submit S/MIME Capabilities Certificate Extension as Informational RFC

January 05
     Final S/MIME version 3.1 interoperability matrix

February 05
     Request advancement of CMS Algorithms to Draft Standard
     Request advancement of CMS to Draft Standard
     Request advancement of ESS to Draft Standard
     Request advancement of CERT to Draft Standard
     Request advancement of MSG to Draft Standard
     Last call on RSA KEM algorithm specification

January 06
     Submit RSA KEM algorithm specification as Proposed Standard

---

From: Ben Littauer <[email-masked]>
Date: Thu, 02 Sep 2004 12:14:16 -0400

Anders, et al,

I'm working with the "competition", i.e. the Open Group.  We have indeed
just launched a certification program for domain encryption and signing
based on a profile of S/MIME.  This work was done independently of, but
highly conscious of, IETF efforts in the area.  In fact, the profile used by
the program was authored by Blake Ramsdell, and we have every intention of
seeing it promulgated as widely as possible.

There are definite shortcomings in the program as it exists today,
primarily, as has been pointed out, in the area of key distribution.  The
current specification leaves this as a fundamentally manual process.  Over
time, as S/MIME gateways proliferate, we hope that the NEED for a more
scalable mechanism develops, but for now penetration of this technology is
so sparse that the more urgent need is to have products that can
interoperate on the mail and key exchange level at all.

I encourage all who are interested in this area to consider attending an
Open Group session on this at one of their meetings.  The next meeting is in
Berlin toward the end of September, but it will be primarily informational
with respect to the gateway certification program.  The following meeting,
in October in New Orleans, will have significant discussions on "v2" of the
certification program.  Please visit http://www.opengroup.org/messaging for
more information.  

In sum, the Open Group considers itself IN NO WAY competitive to the IETF,
and we would welcome participation from all interested parties.

-ben-

> From: Anders Rundgren <[email-masked]>
> Date: Wed, 1 Sep 2004 21:18:04 +0200
> To: Craig McGregor <[email-masked]>
> Cc: "Sean P. Turner" <[email-masked]>, SMIME <[email-masked]>
> S/MIME gateways could use all existing S/MIME specifications and not be
> limited to only signing outbound e-mail. e.g. Encryption
> over the untrusted networks that transports messages between domains that
> might otherwise have some level of trust.
> 
> I would also like to see an interoperable S/MIME Gateway||Domains||Entities
> standard or specification. I have had some past
> experience at making a limited set of S/MIME gateway software talk to each
> other reliably. This was more challenging at that time
> S/MIME Gateway signing and encryption is quite possible in a closed-community
> of domains today - example: http://e.govt.nz/see/mail/
> (Since November 2000)
> 
> If it was possible to solve key management, PKI trust and legacy
> interoperability (including mailing-list behaviour) using something
> that scales to an open community then an S/MIME gateway approach could
> certainly work in the open community. Solving all three of
> To include Stefan's work in the working group we need to modify the working
> group's charter (we also needed to update the dates
> anyway because some are way off).  Attached is the proposed modification.
> Please respond with any comments by  Friday.
> 
> Cheers,
> 
> spt
> 
> 
> 
> 
> 
> The S/MIME Working Group has completed a series of Proposed Standards that
> comprise the S/MIME version 3.1 specification. As part of
> the specification update, a new suite of "mandatory to implement" algorithms
> was be selected. Current efforts update and build upon
> The Cryptographic Message Syntax (CMS) (RFC 3852) is cryptographic algorithm
> independent, yet there is always more than one way to
> use any algorithm. To ensure interoperability, each algorithm should have a
> specification that describes its use with CMS.
> To aid implementers, documents containing example output for CMS will be
> collected and published. Some of the examples will include
> 
> CMS, as well as S/MIME version 3 and later, permit the use of previously
> distributed symmetric key-encryption keys. Specifications
> for the distribution of symmetric key-encryption keys to multiple message
> recipients will be developed. Mail List Agents (MLAs)
> To aid initial determination of recipient's cryptographic capabilities a
> specification will be developed allowing S/MIME
> capabilities to be stored and asserted in X.509 certificates based on the
> X.509 certificate and CRL profile developed by the PKIX
> Working Group.
> 
> The working group will perform necessary interoperability testing to rogress
> the CMS and S/MIME specifications to Draft Standard.
> The CMS specification depends on the RFC 3280. This profile must progress to
> Draft Standard before CMS and the other S/MIME
> specifications can progress to Draft Standard. Assuming timely progress by the
> PKIX Working Group, the S/MIME specification can