Apologies for the unclear insertions in my earlier posting.
Date: Fri, 25 Jun 1999 16:48:59 -0400
From: Larry Stoddard <m(_dot_)stoddard(_at_)ieee(_dot_)ca>
I would like to suggest an additional item for the charter. Currently
there is no support for addresses that are role based (ie
support(_at_)company(_dot_)com). Here are some examples of problems that
need to be
Suppose there are ten people who need to read mail sent to
support(_at_)company(_dot_)com, 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
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 "support(_at_)company(_dot_)com" role is
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 support(_at_)company(_dot_)com I am normally answered by
joe(_at_)company(_dot_)com 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
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.
25 Molesworth Street