Re: sketch of a simple authentication protocol

I have been enquiring a little about the feasibility of the protocol  
sketched by Toby and illustrated  below for easy reference. It does  
seem to be technically possible, even if it requires some hacking  
around. More news later as the implementation proceeds.

Proposal compared to X.509
--------------------------

As I am learning more about SSL I had a few thoughts on how this  
proposal compliments and distinguished itself from X.509 on which SSL  
is built.

  It is clear that we are augmenting the X509 Distinguished Name [2]  
with a URI, in particular a http URL, and in some respects augmenting  
the Public Key Infrastructure (PKI) [3] with Linked Data. Let me  
consider each in turn:

   1. Distinguished Name enhancement

     I don't know that much about X500, so I can't tell what the  
advantages or problems with this protocol/naming system are by  
experience, though I did find a detailed, interesting and severe  
critique [5]. The Semantic Web seems to generalize above this, as it  
deals with all unique identifiers under the topic of URIs, and it has  
a system that works - better even: it works with the web.

    The case that we are enhancing X.509 can be made by realizing that  
it should be possible to add to the SSL certificate an additional URI  
id [4]. Essentially we could then make the statement:

   <distinguishedNameURI> owl:sameAs <foafid> .

By doing this the foaf id would be itself part of the certificate I  
suppose and so be vouched by the Certification Authority. Perhaps this  
reveals a problem with CAs: would CA.s be happy to vouch for a foaf  
id, even if they don't control the contents? If they did then it could  
slightly reduce the need for the foaf resource to return information  
about the key id identifying the user, or enhance the trust of that  
foaf id. Something to think about.

  2. PKI enhancement

    The URI for the user identity is also the place where the  
attributes can be found. So there is no need to pass the attributes in  
the certificate [5]. They can be fetched in a global distributed  
system known as the web, with no central point of control, no  
authorization bottleneck, when and if they are needed. As RDF is  
extremely flexible and well defined, extending it in a clear and well  
documented manner is no problem: every relation can be clicked on to  
find its meaning [6]. Another advantage of this PKI is that it should  
be easy to revoke a certificate. No need for revocation lists. If the  
foaf id of the agent no longer points to the certificate signature,  
the certificate can be deemed to be invalid. All the user would need  
to do to change his certificate is to create a new one, and publish  
its signature to his foaf file. In a semantic address book such as  
Beatnik [7], that could be done with the click of a button.

Limitations of the proposal
----------------------------

In the mean time, while searching for solutions I chatted on irc with  
Perry Nguyen [1] who did point out a few limitations of the proposal.  
Of course every proposal will be a tradeoff between different  
constraints, and so will have limitations. OpenId's limitations for  
example stem from trying to work around the limitations of browsers,  
which is also its big advantage. Still it is useful to list some of  
these, if only because some of these may easily be fixed with a little  
thought, others may have some good workarounds, and others may make us  
more modest. :-)

   1. Man in the middle in step 1

    Yes, that is a problem with any web site. All the unencrypted  
pages could be hijacked by a man in the middle and think links to the  
protected file could be redirected to some other service. This will  
only work if the other service can serve its https pages with a key  
that could be deemed to belong to Juliette. So the question outlined  
here is how does Romeo get to know Juliette's public key?

	The Web of Trust could be made to work here. If people use the  
wot:identity relation between a key and a foaf:Agent to identify the  
agent, in the way the foaf:openid, foaf:mbox, foaf:homePage and other  
relations do, then Romeo could have some confirming evidence as to the  
validity of the public key from his social network. Of course these  
will be out of date in the social network if Juliette changes her  
public key, but that should be relatively rare. When that happens it  
is reasonable to expect people to be on their guard.

   2. Man in the middle in step 2

    That is a rejoins point 1 above. It helps to have Juliette's  
public key, if Romeo wants to be sure that he is communicating with  
her server. Currently Juliette can pay for a public key from a CA, but  
it costs, and if someone steals it, it may take long before the  
expiration time on the key times out [5]. I don't think browsers do  
much checking of certification revocation lists. So the web of trust  
may again work much better.

   3. Man in the middle in step 3

   In the diagram this is not protected. The foaf file contains the  
signature of Romeo's key. If this were changed this would leave the  
door wide open to abuse. Does this mean that foaf files should be  
behind https, even for the non protected files? Notice that we would  
be more secure than OpenId, which does not require the openid URL to  
be protected. I think I heard that https could be used just to sign a  
file without encrypting the communication. When this happens is it  
proxy friendly? I mean can, and do, proxies cache the representation  
in order to reduce load on the server? What would be gained if romeo  
used his private key to sign the representation?


   So these are a few thoughts I gathered on my search to implement  
Toby's solution. Feedback welcome of course.


	Henry Story

Home Page: http://bblfish.net/


[1] http://www.hanhuy.com/pages/resume
[2] http://en.wikipedia.org/wiki/Distinguished_name
[3] http://en.wikipedia.org/wiki/Public_key_infrastructure
[3] http://httpd.apache.org/docs/2.2/ssl/ssl_intro.html#certificates
[4] My guess is that this would be possible theoretically, though not  
easy when dealing with the Java API.
     I am not sure how one would go about it.
     http://java.sun.com/j2se/1.5.0/docs/api/java/security/cert/X509Certificate.html
[5] I did find a very critical document of X.509 on wikipedia  
"Everything you Never Wanted to Know about PKI but were Forced to Find  
Out"
     http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf
[6] http://blogs.sun.com/bblfish/entry/get_my_meaning
[7] for more info on Beatnik, see the slightly hidden link on https://sommer.dev.java.net/

On 2 Apr 2008, at 16:52, Story Henry wrote:
> Hi Toby,
>
> I thought it would be fun to represent your answer [1] with a  
> Sequence Diagram to make sure I have really understood what you are  
> saying. It is even simpler that the previous sketch.