Subject: Charter Revision

From: Russ Housley <[email-masked]>
Date: Mon, 21 Jun 1999 16:17:29 -0400

I have finally taken all of the inputs that I received and combined them
with stuff that I made up out of thin air.  I had to do this because not
everyone sent in information about their plans.

Anyway, here is my proposed revised charter.  Please comment.

Russ

= = = = = = = = = = 

S/MIME Mail Security (smime)

Chair:
     Russ Housley <[email-masked]>

Security Area Director:
     Jeffrey Schiller <[email-masked]>
     Marcus Leech <[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 five Proposed Standards that
comprise the S/MIME version 3 specification.  Current efforts build
on these base specifications.

The use of Diffie-Hellman Key Agreement as the mandatory to implement
key establishment mechanism may expose some implementations to 
vulnerabilities based on "small subgroup" attacks.  An informational 
document will be prepared describing techniques that can be used to 
avoid these attacks.

The Cryptographic Message Syntax (CMS) 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 decribes its use with CMS.  Specifications for the use of optional
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 attributed defined in the Extended Security Services (ESS) 
document.

Current methods of publishing certificates in the Directory do not 
allow the inclusion of secondary support information such as the 
SMimeCapabilities attribute.  A method of publishing certificates 
along with authenticated secondary support information will be 
defined. 

In some situations it would be advantageous for the CMS RecipiontInfo
structure to support additional key management techniques, including
cryptographic keys derived from passwords.  A mechanism to facilitate 
the definition of additional key management techniques will be defined.

S/MIME version 3 supports encrypted mail lists.  Specifications for the 
distribution of symmetric mail list keys to mail list agents (MLAs) and
message recipients will be developed.  The specification will be 
cryptographic algorithm independent.

S/MIME version 3 supports security labels.  Specifications that show 
how this feature can be used to implement an organizational security 
policy will be developed.  Security policies from large corporations will
be used as examples.

S/MIME version 3 can be used to protect electronic mail to and from a
domain.  In such an environment, S/MIME v3 processing is performed by 
message transfer agents, guards, and gateways in order to provide 
"Domain Security Services."  Mechanisms are needed to solve a number of 
interoperability problems and technical limitations that arise when  
domains supporting different security policies wish to interoperate.

The S/MIME Working Group will attempt to coordinate its efforts with the
OpenPGP Working Group in areas where the work of the two groups overlap.

Goals and Milestones:

History:
     First draft of small subgroup attack avoidance.
     First draft of certificate distribution specification.
     First draft of domain security services document.
     First draft of CMS and ESS examples document.
     First draft of KEA and SKIPJACK algorithm specification.
     First draft of IDEA algorithm specification.

July 1999:
     First draft of security label usage specification.

August 1999:
     Last call on small subgroup attack avoidance.
     Last call on KEA and SKIPJACK algorithm specification.

September 1999:
     First draft of CMS RecipiontInfo extension.
     First draft of mail list key distribution.
     Last call on certificate distribution specification.

November 1999:
     Updated draft of domain security services document.
     Last call on security label usage specification.
     Submit small subgroup attack avoidance as Informational RFC.
     Submit KEA and SKIPJACK algorithm specification as Informational RFC.

December 1999:
     Last call on CMS and ESS examples document.
     Last call on IDEA algorithm specification.
     Last call on CMS RecipiontInfo extension.

January 2000:
     Last call on mail list key distribution.
     Submit certificate distribution specification as a Proposed Standard.

February 2000:
     Submit security label usage specification as Informational RFC.

March 2000:
     Submit CMS and ESS examples document as Informational RFC.
     Submit IDEA algorithm specification as Informational RFC.
     Submit CMS RecipiontInfo extension as a Proposed Standard.
     Submit mail list key distribution as a Proposed Standard.

July 2000:
     Last call on domain security services document.

September 2000:
     Submit domain security services as Experimental RFC.

---

From: "Pawling, John" <[email-masked]>
Date: Tue, 22 Jun 1999 11:12:45 -0400

Phill,

I agree that the S/MIME WG should not duplicate the work of the PKIX WG.
The PKIX WG is the place to debate the use of ACs, not the S/MIME WG.
However, the existing CMS-13 I-D (soon to be an RFC) already imports the
1997 X.509 AC syntax (because it is anticipated that the originator's AC(s)
may need to be carried in the CMS security heading).  My point is that any
change away from the 1997 AC syntax is a change to CMS.

I believe that the PKIX WG's goal is to devise an AC strategy that is
consistent with X.509.  If the PKIX WG achieves that goal then it is
appropriate for CMS to import the AC syntax from X.509.  I believe that it
is premature to argue about "PKIX vs. X.509" because they should specify
identical syntaxes.

In summary, I still believe that my proposed text should be added to the
charter because there will be changes to CMS related to the AC syntax.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc.
[email-masked]
============================================

---

From: Carlisle Adams <[email-masked]>
Date: Tue, 22 Jun 1999 13:25:45 -0400

Hi Phill,

> ----------
> From: 	Phillip M Hallam-Baker[SMTP:[email-masked]]
> Sent: 	Tuesday, June 22, 1999 10:57 AM
> To: 	Pawling, John; [email-masked]
> Subject: 	RE: Charter Revision
> 
> > 1) There is significant work being done in the ISO committees (i.e.
> FPDAM)
> > that will impact the X.509 Attribute Certificate syntax.  
> > Recommend that we
> > add the following text to the charter: "CMS imports the Attribute
> > Certificate syntax from X.509.  If the AC syntax is changed (as is
> > expected), then CMS will be enhanced to import the revised syntax."
> 
> This is definitely NOT a topic for S/MIME.
> 
> In the first place CMS should be importing semantics from PKIX, not
> X.509. 
 
Fair enough.  Note, however, that John did not suggest importing semantics
from X.509; he suggested importing syntax from X.509, which is the correct
thing to do.  This should lead to no conflict with what PKIX is doing
(recall what the "X" in PKIX stands for...).

> The approach S/MIME should take is to look to see what _functionality_
> it wants to add to S/MIME to solve _problems_. Simply adding technology
> for the sake of it is a very bad move.
> 
> The proper place to address attribute certificates would be either
> PKIX or more likely a new group focussed on some _use_ of attribute
> certificates. 
 
As John has pointed out, it has been envisioned from the start of the S/MIME
Working Group that Attribute Certificates might be the technology that makes
labeling of e-mail messages useful.  So what you're asking for above may be
precisely the reason that it is valuable to include the text that John
suggested...

Carlisle.

---

From: Larry Stoddard <[email-masked]>
Date: Fri, 25 Jun 1999 16:48:59 -0400

I would like to suggest an additional item for the charter. Currently
there is no support for addresses that are role based (ie
[email-masked]). Here are some examples of problems that need to be
addressed.

Suppose there are ten people who need to read mail sent to
[email-masked], how would this be handled without sharing the
private key, which for this example is prohibited by policy. As well any
of the ten support people need to be able to send messages that can be
later
verified as being from the individual sender and that the sender is a
member of the support role.

Also suppose the CEO of a company is on vacation and he wishes his EA to
check his mail. But the CEO's mail is not encrypted for his EA and he
doesn't want the EA to have access to his personal email that is
encrypted for the same address. As well the CEO wants to delegate his
CEO signing authority to the COO for the duration of his vacation. 

Another feature the CEO wants is the ability to have his secretary draft
and address messages for him that he can later sign (without cutting and
pasting).

The above situations are most elegantly solved by defining S/MIME
extension(s) and a standard set of role attributes that support the
concept of role based messaging. By adding extensions to S/MIME to
support "draft messages", role signing authorities, and private
role-owner only messages, email developers will be able to create more
flexible mail solutions for large corporate and government users. Work
in PKIX on attribute certificates can be used for the role attributes
and support the delegation of role authority. 

Therefore I recommend that the smime WG charter include the
investigation of S/MIME extensions to support role based messaging and
standardization of role based messaging attributes and certificates that
are compliant with the attribute certificate work being done in PKIX.

Larry Stoddard
CFIOG IPC

[email-masked]

---

From: Graham Klyne <[email-masked]>
Date: Sat, 26 Jun 1999 09:24:31 +0100

>[email-masked]). Here are some examples of problems that need to be

I know this isn't central to the issue you raised, but in case it has any
relevence, may I draw attention to RFC 2412:

                             MAILBOX NAMES FOR
                   COMMON SERVICES, ROLES AND FUNCTIONS

#g

------------
Graham Klyne
([email-masked])

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 28 Jun 1999 12:48:37 -0400 (EDT)

> Date: Fri, 25 Jun 1999 16:48:59 -0400
> From: Larry Stoddard <[email-masked]>
> 

I'm not sure how any attributes or extensions could solve this
problem.  If a message is both encrypted and sent to a role address,
then all ten individuals need to have access to the decrypted message.
That can be done by sharing the role's encryption private key, or by
having a proxy which decrypts the message and forwards it to the
"support officer on duty".  Why should sharing the role encryption key
be prohibited by policy, assuming that it's OK for all ten people to
have 7x24 access to all incoming messages?

OTOH, policy prohibits (or should prohibit) sharing of signing keys,
so there is always individual accountability for outgoing messages.
A signing proxy could be used to strip off the signer's individual
identity on outgoing messages while maintaining audit records, or you
could use 10 different signing certs with the same role name if external
visibility of the signing key is not an issue.

I believe that establishing a "[email-masked]" role is exclusively
a key/cert management issue.  What changes/additions to S/MIME did you
envision being needed?  What purpose would machine-readable message
attributes serve in this application?

> encrypted for the same address.

Recipient-based access control (where the EA knows the CEO's private
key but is on his honor not to read messages marked with a
machine-readable "personal" attribute) is not a particularly secure
solution. It would be possible to define a "personal/official" message
flag that every sender would have to set appropriately, *and* rely on a
trusted proxy to not forward personal messages to the EA.  But it seems
much simpler to just use a role cert "Roger Smith, CEO" and a
personal cert "Roger Smith" with different keys, and share just the
role private key with the EA.  Human senders would select the
appropriate certificate for personal or official messages based on the
DN. What advantage would (machine-readable) message attributes have over
(human-readable) DNs in this application?

> and address messages for him that he can later sign (without cutting and

What involvement should the S/MIME working group have in defining
attributes to support workflow?  Message attributes such as Draft
markings seem to be equally applicable to unprotected and protected
messages, so the definition of such attributes seems more suited to a
working group in the Applications area than one in the Security area.
Workflow applications might need to understand normal S/MIME security
features (such as wrapped and parallel signatures), but having the
S/MIME WG define interoperablility specifications for workflow sounds
like the tail wagging the dog.