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

Re: Out on a loop

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

At 11:24 PM 12/9/97 -0200, Ed Gerck wrote:
>On Tue, 9 Dec 1997, Carl Ellison wrote:
>-> To me, there are not apples and speedboats.  Rather, there is 
authorization 
>-> which is injected by the verifier into a so-called root key and passed 
>-> from that root key through certificates, possibly constrained or 
restricted, 
>-> into the eventual request where it is delivered to the verifier as part 
of a 
>-> request for some kind of action.  This model of trust computation fits all
>-> known certification examples.  Even though it is foreign to X.509 thinking,
>-> in particular, it applies to X.509.  The authorization in this example 
flows
>-> in a loop (circuit) from verifier back to verifier.  To use an electical 
>-> example, the verifier has both battery and ammeter.
>-> 
>
>Carl,
>
>This issue bears on your earlier comment that PGP's trust model is not
>able to pass full authority, while X.509, SDSI and raw SPKI are able to,
>to which I answered negatively, with the partial copy above.  While I
>think that PGP is a wee bit out of context here, your mention of X.509
>makes me feel a teeny-weeny more confortable to comment further on this
>issue -- emphasizing X.509 but with a dash of PGP at the end. 

[details snipped]

Ed,

I fear we still have a disconnect.

Your explanation followed the X.509 mindset.  This is something where Bob 
Jueneman should probably chime in as well, because I believe this is a 
fundamental difference between the SPKI and X.509 worlds.

The things you cited as needing to be verified were the characteristics that 
X.509 CAs have talked about and consider important.  It's not all their 
fault of course.  These are things cryptographers talk about, augmented by 
legal issues first raised by Michael Baum.  That is, you have an accepter of 
certificates first worrying about Certification Practice Statements, key 
management, key length, crypto box security, personnel security, and such 
things.

SPKI made its radical departure from X.509 by saying that we have *two* 
issues here -- key security and authorization -- and the authorization was 
getting inadequate attention.  We care about both, but of those two 
authorization is the more important.

Let me give an example, because I'm pressed for time.

Let us assume I have an SPKI verifier in the CyberCash firewall.  It is 
looking to verify that some caller has the authorization to telnet into the 
private LAN it protects.  Therefore, that verifier has an ACL entry that 
delegates (tag (telnet)) to some principal.  When we look at characteristics 
of various certificate issuers in order to choose the one to delegate that 
permission to, we look for the business organization that has the authority 
to delegate such authorizations.  We find exactly one: CyberCash Operations 
Group.  We have then made our decision for the ACL -- and for what has been 
called "root key empowerment" without looking at all at their key management 
practices.  The decision stands no matter how poor their key management is.  
Of course, we care about their key management practices and their human 
procedures for identifying employees and their remote access rights, but 
those are secondary.  The decision of whom to empower has been made.  If an 
alternative key to empower had been VeriSign's with their known superior key 
management and carefully crafted CPS, they would still not have been in the 
running since they have no authority in the area we care about.


So, to help you break loose from your X.509 mindset, let me suggest a 
thought experiment.  X.509 has had us all try to pretend that what we care 
about is CPS and key protection and such things as the most important thing 
and that second comes some practice of establishing identity in a way courts 
would accept and left for future discussion is the issue of passing 
authorization.  Instead, how about you spend a month or two imagining the 
SPKI world in which the most important thing (and, if push comes to shove, 
the only important thing) is authority to speak on matters contained in the 
authorization field while *no* CPS is ever written or read, key management 
is an individual affair (as with PGP today) and any names are strictly for 
the issuer's own convenience.

 - Carl

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3

iQCVAwUBNI7D9xN3Wx8QwqUtAQHTCwP/b3rdZPbIZA84kY1zX4JiKWdO+uaRi0s/
wpuWFaeTxqSwjuwkAM9+R0RlC4Du8jm6esgPtTNi1CLNv6JYNp4HNEAn4tyYFhmH
UihedoH9H8UzIR3KfkNaabalKYsdJdRmV9CL+ce5524fbm34/9NiF6ohukUe3rBZ
323c0ac8coU=
=tXpl
-----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 08FF BA05 599B 49D2  23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |
+------------------------------------------------------------------+
References: