Re: Charter Revision

[Antonio Maña <[e-mail]>]

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 [e-mail]) 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: [e-mail] !
  !              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: [phone]        Fax: [phone] !
  +--------------------------------------------------------+
  ! 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         !
  +--------------------------------------------------------+