Larry,
first of all thank you for your comments,
Larry Stoddard escribió:
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.
You are right about smart cards, but I think that the identity problem
can be solved without smart cards. Also it depends on the type of key
(specially the 'container' of the key not the key itself) that you can
store several keys in a smart card.
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.
Of course, ideally the authorization should be separated from the identity,
but roles can be considered identities as well. The authorization of a role
is in most cases intrinsic to that role, for example if I am sure that you
are part of the support team of some company I can trust that any answer I
receive from you regarding products of that company is correct. In that
case I don't need an authorization that says that your can answer questions
about products of that company.
You say that the role owner should be able to delegate his role without
involving the CA. That's because you are thinking about a commercial CA
that issues generic 'identity' certificates. If the owner of the role can
act as CA the problem disappears. I don't see the difference between issuing
a 'identity' certificate that relates a role to a specific email address -and
the corresponding public key- (which could also contain attributes to solve the
authorization issues if needed) as I propose or issuing an 'authorization'
(which I suppose is also a certificate) related to an existing 'identity'
certificate. The second solution is more complex and, in most cases, I don't
care 'who' (what physical person) is answering if I know that (s)he is allowed
to play the role that corresponds to my request.
Looking from another perspective, who should give the authorization to play
some role? Probably not the role owner because otherwise there has to be
some root to that chain that has an auto-authorization. I think that the
authorization for some role (say support(_at_)software(_dot_)company(_dot_)com)
should come from
the upper level in the organization of the company (software.company.com in the
example)
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.
That's again because you are supposing an expensive 'identity' certificate
with a long lifetime, an using CRLs to revoke certs. Would you agree that
the solution I propose is at least equivalent to the identity+attribute
solution if my 'identity' certificate could be issued and revoked as
easily (locally) as the attribute certificate you propose?.
Cheers,
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 !
+--------------------------------------------------------+