Subject: RE: Re:Charter Revision

From: [email-masked]
Date: Tue, 29 Jun 1999 09:54:39 -0400

-----Original Message-----
From: dpkemp [SMTP:[email-masked]]
Sent: Monday, June 28, 1999 5:49 PM
To: ietf-smime
Cc: dpkemp
Subject: Re:Charter Revision

> Date: Fri, 25 Jun 1999 16:48:59 -0400
> From: Larry Stoddard <[email-masked]>
> 
> 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.

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.

[O'Malley, Bartley]  From a usability standpoint I would have thought it was 
acceptable for a member of the support team to sign a message personally 
without the need for a proxy to re-sign a message. In my experience, while I 
may send a request to [email-masked] I am normally answered by 
[email-masked] and then enter a dialog with this person. In any case it is 
probably more practical for the proxy, if used, to simply counter sign the 
message and for both signatures to go out. I would imagine that this would be 
managed via proxy configuration rather than S/MIME extensions.

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?

> 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.

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?
[O'Malley, Bartley]   I feel that there is a real need for some way to 
facilitate this type of processing. Perhaps we could introduce a keyusage 
identifier which indicates that a key is to be used for "recipients eyes 
only(personal key)" or " including delegated assistant(role key)" or "company 
email(company public email key)" this would allow/require multiple encryption 
keys to be stored in a certificate. I suppose that I am actually suggesting an 
enhancement to X509.  

> 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).

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.

---

From: Antonio Maña <[email-masked]>
Date: Wed, 30 Jun 1999 13:40:38 +0200

> Subject: Re:Charter Revision

SKIP

> (human-readable) DNs in this application?

I agree completely with David Kemp on this. It is a good idea that the
implementation of the 'role' feature is human readable. The email
system has been used in this way (without security) by using different
pseudonyms (i.e. alias). Therefore Mr. Roger Smith could solve his
problem without attribute certificates or any other change to the
current situation simply. All he has to do is set different
adresses for his roles. Therefore the address [email-masked]
can be used for his personal messages using the key related to this
account and the corresponding certificate. The address [email-masked]
or [email-masked] can be used in the same way to identify
his CEO role. Even if both accounts are aliases and are redirected to
some other account, the messages sent to each account will be encrypted 
using different keys, so Roger can give the (curious) EA the key that
decrypts messages sent to his official account without risk.

Antonio Maña.

                            \|||/
                           ( . . )
  +------------------o000-----U------000o------------------+
  !           _   ,                                        !
  ! Antonio Mana Gomez               eMail: [email-masked] !
  !              http://www.lcc.uma.es/~amg                !
  +--------------------------------------------------------+
  ! Departamento de Lenguajes y Ciencias de la Computacion !
  !      E.T.S.I.Informatica.        Desp. 1.2.B.19        !
  !                  Campus de Teatinos.                   !
  !                 29071 MALAGA (SPAIN)                   !
  +--------------------------------------------------------+
  ! Phone: (+34) 5 213 27 54        Fax: (+34) 5 213 13 97 !
  +--------------------------------------------------------+
  ! PGP KEY TYPE:                                          !
  !   RSA 1024                                             !
  ! KEY FINGERPRINT:                                       !
  !   7900 CDBB 9766 AB87  F0CE 5B4F 3DF1 BA56             !
  ! KEY SERVER:                                            !
  !   Cert'eM at http://socrates.crypto.lcc.uma.es         !
  +--------------------------------------------------------+

---

From: Larry Stoddard <[email-masked]>
Date: Wed, 30 Jun 1999 17:32:58 -0400

The problem with the key/cert management approach is that it requires
many keys. This will eliminate smart card based solutions as there is
not enough space to hold multiple keys and key histories. Unless you use
multiple smart cards, which would mean playing musical smart cards to
read all your mail. Lending a token means that you are giving access to
everything protected by the token, including the ability to sign. The
problem with lending encryption keys is that some authentication schemes
use encryption keys instead of signing keys to do anonymous
authentication.

Also for those that lease PKI services there will be an additional
charge for each cert issued, so there is an incentive to minimize the
number of certificates required. The goal is to separate authorization
from identity as any change in authorization will result in revocation
of the identity certificate. Also the management of roles is something
that should be handled in as distributed a fashion as possible, ideally
the role owner should be able to delegate his role without involving the
CA. 

How do you foresee dealing with temporary delegation of signing
authority for a role? Issuing identity certs and then revoking them
would seem to be an extreme way of handling this and means more work for
LRA and CA administration, not to mention longer CRLs. An attribute
certificate with a short lifetime is more practical, especially if the
attribute cert can be issued by the local role owner.

Larry Stoddard