Subject: RE: Charter Modification

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 7 Sep 2004 14:31:53 +0100

This text sounds as it implies a substantial expansion of scope of the
capabilities issue.

I don't oppose this change but suggest then that we change "a
specification will be developed" to "specifications will be developed".

The type of complex approaches recently discussed on this list to
accommodate dynamic assertion of sMIMECapabilities doesn't mix very well
with the simple and direct task to document the use of the existing
attribute structure as a certificate extension.

I therefore strongly suggest, in case the WG wants to pursue that path,
that the recent discussed expanded task is separated into its own work
item and that the WG assigns another editor for that work.

I don't have the time and capacity to edit that specification.

Stefan Santesson 
Microsoft Security Center of Excellence (SCOE) 

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sean P. Turner
Sent: den 7 september 2004 13:12
To: SMIME
Subject: Re: Charter Modification

I'm going to forward the charter on to Russ with Tony's suggested
changes.   As for the other issue of S/MIME gateways, we'll see how it
plays out in the other working group.

Sean P. Turner wrote:

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]> <mailto:[email-masked]> 
     Blake Ramsdell <[email-masked]> <mailto:[email-masked]> 

Security Area Director:
     Russ Housley <[email-masked]> <mailto:[email-masked]> 
     Steve Belovin <[email-masked]> <mailto:[email-masked]> 
 
Security Area Advisor:
     Russ Housley <[email-masked]> <mailto:[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.

Stike the following

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.

And replace it with:

To aid initial determination of a recipient's cryptographic and other
S/MIME related capabilities, a specification will be developed allowing
these capabilities to be distributed using method(s) in addition to that
currently specified 

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: "Sean P. Turner" <[email-masked]>
Date: Tue, 07 Sep 2004 13:16:21 -0400

Stefan,

I guess I didn't see this as a big change. I'm also not sure anybody
was really suggesting a more dynamic approach just that red flags might
be raised by PKIX if we assume we're going to stick it in a cert.  I
personally don't think PKIX is going to care because PKIX is tring to
close down.  And, I think there's only a couple of "simple" ways to
distribute the attribute: in a respository or in a cert.  The
repository case is already defined we're just doing the other one.
Besides, you don't have to implement it if you don't want to.

spt

Stefan Santesson wrote:

This
text sounds as it
implies a substantial expansion of scope of the capabilities issue.

I
don’t oppose this
change but suggest then that we change ”a
specification will be developed“ to
“specifications will be developed”.

The
type of complex approaches
recently discussed on this list to accommodate dynamic assertion of
sMIMECapabilities
doesn’t mix very well with the simple and direct task to document the
use
of the existing attribute structure as a certificate extension.

I
therefore strongly
suggest, in case the WG wants to pursue that path, that the recent
discussed
expanded task is separated into its own work item and that the WG
assigns
another editor for that work.

I
don’t have the
time and capacity to edit that specification.

Stefan
Santesson

Microsoft
Security Center
of Excellence
(SCOE)

From:
[email-masked]
[mailto:[email-masked]] On
Behalf Of Sean P. Turner

Sent: den 7 september
2004 13:12

To: SMIME

Subject: Re: Charter
Modification

I'm going to
forward the charter on to Russ with
Tony's suggested changes.   As for the other issue of S/MIME
gateways, we'll see how it plays out in the other working group.

Sean P. Turner wrote:

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

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:

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.

Stike the
following

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.

And replace it with:

To aid initial determination of a recipient's cryptographic and other
S/MIME related capabilities, a specification will be developed
allowing these capabilities to be distributed using method(s) in
addition to that currently specified

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

September 04

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

February 05

January 06