[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible SPKI simplifications



-----BEGIN PGP SIGNED MESSAGE-----

At 12:49 PM 8/19/97 -0400, David Black wrote:
>> This all looks very  like X.509's current model where
>> one simple cert binds name to key (could be Carl's nemesis
>> "global-names", or a SDSI non-global name model), and another
>> authorization cert specifies authorization policy inputs.
>
>That shouldn't be any surprise.  In order to do late binding of a subject
>(one of the major claimed advantages of SDSI names), it is necessary to
>separate the binding of name to key from the binding of authority to name.
>Hence late binding requires two certificates, although SPKI doesn't care
>whether they have common or separate revocation lists.  What you may have
>missed that the telent example description took an example straight out of the
>current SPKI draft and suggested a different certificate syntax to achieve the
>same semantics, so the X.509-like functionality that you describe is in the
>current SPKI draft.

There are significant differences between the X.509 naming and SPKI naming.  
It is true that one can, if one chooses, employ names and issue a delayed 
binding cert binding a named principal to a permission.  To that extent, 
SPKI/SDSI captures what some people wanted to do via X9.57.  However, if you 
draw the certificate loops for these two cases, you'll see that the 
SPKI/SDSI example uses one loop with one authorization at the left (from an 
ACL) empowering the loop -- while the X9.57 example uses two loops, one for 
naming and one for authorization.  The two loops have different code, 
because the certs involved are different -- but in the SPKI/SDSI case there 
is one 5-tuple evaluator that reduces the single loop whether or not the 
issuers have chosen to use names.  That structure is the significant 
difference to which I referred.

This is apart from what I consider to be the most important difference -- as 
Peter noted -- that global names (a la X.500 or PEM) are a security flaw.

 - Carl

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQCVAwUBNAZLnlQXJENzYr45AQFG1gP7B7g+iK4knKOF3q+hctvt0Gxohpi3wEdh
rps/p9Nk1QMFLbclx4tt/aFSDVC4kZoCTylA3KmvpnfeD9yQHMqStWq8MBRHTVuT
3wkqEsNjTjEo2PZUQrJpiaVmXvA5b+3t62rATa7by02OC8cTd+HL/q60gdBrZsC1
vQdt3j0wlZs=
=31T4
-----END PGP SIGNATURE-----


+------------------------------------------------------------------+
|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street   PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |
+------------------------------------------------------------------+


Follow-Ups: References: