Subject: WG Review: Some PKIX and SMIME (spasm)

From: The IESG <[email-masked]>
Date: Fri, 17 Jun 2016 09:33:37 -0700

A new IETF WG has been proposed in the Security Area. The IESG has not
made any determination yet. The following draft charter was submitted,
and is provided for informational purposes only. Please send your
comments to the IESG mailing list ([email-masked]) by 2016-06-27.

Some PKIX and SMIME (spasm)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  TBD

Assigned Area Director:
  Stephen Farrell <[email-masked]>

Security Area Directors:
  Stephen Farrell <[email-masked]>
  Kathleen Moriarty <[email-masked]>
 
Mailing list:
  Address: [email-masked]
  To subscribe: https://www.ietf.org/mailman/listinfo/spasm
  Archive: https://www.ietf.org/mail-archive/web/spasm/

Charter: https://datatracker.ietf.org/doc/charter-ietf-spasm/

The PKIX and S/MIME Working Groups have been closed for some time.  Some
updates have been proposed to the X.509 certificate documents produced 
by the PKIX Working Group and the electronic mail security documents 
produced by the S/MIME Working Group.

The SPASM (Some PKIX and S/MIME) Working Group is chartered to make
updates where there is a known constituency interested in real 
deployment and there is at least one sufficiently well specified 
approach to the update so that the working group can sensibly evaluate 
whether to adopt a proposal.  The current charter encompasses updates to 
satisfy the following needs:

1. Specify the way to include an i18n email address as a subject
   alternative name and an issuer alternative name.
   draft-melnikov-spasm-eai-addresses is a proposal in this space. 

2. Specify the way to use authenticated encryption in S/MIME. 
   draft-schaad-rfc5751-bis is a proposal in this space.

In addition, the SPASM Working Group may investigate other updates to 
the documents produced by the PKIX and S/MIME Working Groups, but the 
SPASM Working Group shall not adopt any of these potential work items 
without rechartering. No such re-chartering is envisaged until one or 
more of the above work items have been successfully delivered to the RFC 
editor queue. 

Milestones:

TBD