bartley.o'malley(_at_)citicorp(_dot_)com escribió:
-----Original Message-----
From: dpkemp [SMTP:dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil]
Sent: Monday, June 28, 1999 5:49 PM
To: ietf-smime
Cc: dpkemp
Subject: Re:Charter Revision
SKIP
I believe that establishing a "support(_at_)company(_dot_)com" 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?
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 RogerSmith(_at_)company(_dot_)com
can be used for his personal messages using the key related to this
account and the corresponding certificate. The address
CEO(_at_)company(_dot_)com
or RogerSmithCEO(_at_)company(_dot_)com 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: amg(_at_)lcc(_dot_)uma(_dot_)es !
! 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 !
+--------------------------------------------------------+