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
Antonio Maña wrote:
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 !
+--------------------------------------------------------+