[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on client auth
I've been lurking in this list for the last week after meeting Brian at the
JavaOne conference. I've been keeping up on the current discussions but I
haven't had time to look at all the archives yet. As I've been following
this discussion I've kinda of divided it into 4 areas:
1) Public Key Content
2) Public Key Management
3) Public Key Distribution
4) Establishment of "Trust"
I have my opinions in each of these areas, some of them stronger than
others but in a recent message,
>Phillip M. Hallam-Baker said:
>
> . . .
>
>I suggest that SPKI construct a URI for identifying a party or object which
>captures the authority chain, something like:-
>
>WEB:iip@ai.mit.edu The party iip@ai.mit.edu
>WEB:/rsa.com/iip@ai.mit.edu The party rsa.com considers to be
>iip@ai.mit.edu
>WEB:/x.org/iip@ai.mit.edu The party x.org considers to be iip@ai.mit.edu
>WEB:/x.org/rsa.com/iip@ai.mit.edu
> The party x.org considers to be the party
>
> rsa.com considers to be iip@ai.mit.edu
>
> . . .
My response is Bravo! I think the URI/URL model lends itself naturally to
the distribution of public keys. Further it allows flexibility in how keys
are managed at the remote end while providing a common access mechanism. We
are currently doing some research into the feasibility of a Key
Distribution Protocol based on a structure similar to what Phillip
proposed.
In our work we are proposing using the construct:
kdp://ca.you.trust:port/someUsage/someDistinguishingName
This allows an individual or organization to select a CA which they trust
and ask it for the public key of some person trying to perform some
function. There is no perconception of how the CA is structured and the
operator of the CA is free to extend it's usage.
Further, as a user I don't want to have to deal with a bunch of CA's and
decide if I "trust" with each of them. In our architecture we have
introduced the concept of "inherited trust". This allows the CA which I
trust to establish a trusted relationship with another CA. If I ask my CA
for a key which it does not have but can obtain thru a trusted relationship
then I get the key along with a "chain of trust" which shows the derivation
of the key. The user can then determine the acceptability of the key.
We feel this model keeps it simple for the user while allowing a flexible
and extendable CA infrastructure.
Jeff Parrett (starman@llnl.gov)
The stars are the limit!