Subject: Re:Charter Revision(take 2)

From: [email-masked]
Date: Tue, 29 Jun 1999 11:53:28 -0400

Apologies for the unclear insertions in my earlier posting.

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

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

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.  

Bartley O'Malley
Citibank NA
Lewisham House
25 Molesworth Street
London
SE13 7EX
England

Tel +44-171-500-6473
Fax +44-171-500-8880