Subject: Re: Charter Revision

From: Antonio Maña <[email-masked]>
Date: Thu, 01 Jul 1999 12:12:11 +0200

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 [email-masked]) 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: [email-masked] !
  !              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         !
  +--------------------------------------------------------+

---

From: "Flanigan, Bill" <[email-masked]>
Date: Thu, 1 Jul 1999 10:33:12 -0400

Hello Larry,

	Decided to add my nickel's worth.  Please see "BF:" inline comments
below.

Best regards,

Bill Flanigan
> ----------
> From: 	Larry Stoddard[SMTP:[email-masked]]
> Sent: 	Wednesday, June 30, 1999 5:32 PM
> To: 	Antonio Maña
> Cc: 	[email-masked]
> Subject: 	Re: Charter Revision
> 
BF:  Don't see a "business case" yet for a charter revision.

> many keys. 
BF:  Yes, and I currently don't see anyway to avoid this in the foreseeable
commercial future (but see last comment below).

> This will eliminate smart card based solutions as there is
> not enough space to hold multiple keys and key histories. 
> 
BF:  Memory growth and cleaver memory use/management will help.  Then there
is physical size:  I wonder how many cert/key sets would fit into a palmtop
or kneetop?  Probably as many as one needs. 

> Unless you use
> read all your mail.
BF:  I think you will actually end up playing musical certs.  You will be
dealing with a large number of PKIs, as well as a number of cert flavors
that each PKI will have issued.  For example, a "modest" PKI might like to
issue nonRepudiation certs, dataEncipherment certs, and IPSec certs.  And
this hardly scratches the surface as far as the number of variations just
based on the PKIX profile.  (I'm ignoring for now the possibility of root CA
cross certification.)

>  [snip]
> number of certificates required.
> 
BF:  But there seems to be not much incentive to do this as far as
commercial browsers are concerned.

[snip] 

> Issuing identity certs and then revoking them
> LRA and CA administration, not to mention longer CRLs.
> 
BF:  Maybe not.  You might start with a "long-term" nonRepudiation cert as
the I&A basis for obtaining/issuing short-lived certs (SLCs).  If SLCs were
good for only one transaction (with validity periods of seconds or minutes),
CRL posting would not occur.  As for CA administration, this is already a
big problem--especially for big PKIs (with certs in the millions).  Just
think about the bottlenecks of, say, how many certs/second can be issued as
well as directory storage capacity.  So, perhaps, your concerns about all
those certs may go away because cert servers can't issue them fast enough
and directories can't store them!  A final note:  I'm not sure if this
thread needs to continue.  If it does, I really don't think it belongs on
the S/MINE list any longer. 

[snip] 

> Larry Stoddard