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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] 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 <mailto:turners(_at_)ieca(_dot_)com>
To: SMIME <mailto:ietf-smime(_at_)imc(_dot_)org>
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 <turners(_at_)ieca(_dot_)com>
Blake Ramsdell <blake(_at_)sendmail(_dot_)com>
Security Area Director:
Russ Housley <housley(_at_)vigilsec(_dot_)com>
Steve Belovin <smb(_at_)research(_dot_)att(_dot_)com>
Security Area Advisor:
Russ Housley <housley(_at_)vigilsec(_dot_)com>
Mailing Lists:
General Discussion: ietf-smime(_at_)imc(_dot_)org
To Subscribe: ietf-smime-request(_at_)imc(_dot_)org
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