[foaf-protocols] CGI::Auth::FOAF_SSL mumblings

Story Henry henry.story at bblfish.net
Tue Dec 8 20:16:04 CET 2009

On 8 Dec 2009, at 17:08, Toby Inkster wrote:

> I've spent a few minutes this afternoon doing a little work on my Perl
> FOAF+SSL module.
> Interesting features coming up:
> * Now uses RDF::Trine instead of RDF::Redland. This is mostly 
>  an internal change that only "advanced" users are likely to
>  notice.
> * If the certificate's subjectAltName field contains more than
>  one URI, the previous behaviour was to only check the first
>  and ignore all others. Now, it keeps going until it finds a
>  URI which matches the certificate's modulus and exponent.
>  What do other implementations (e.g. libAuthentication) do
>  when presented with a certificate with multiple URIs?

The Java libs we have stop at the first, but I think your behaviour makes sense. This could be very useful as a way of creating failover protection for foaf+ssl logins. If your server is down, and your other server(s) is/(are) up, you may still be able to login.

My guess is that something like this should be tuneable. One thing that very much should be taken into consideration is the time these requests take... So I can imagine it would be acceptable to deem the connection a failure after 10 seconds or so, no matter how many URLs are in the subject alternative name.... 

> * If the certificate has no URIs, or none of the URIs it has
>  match its modulus and exponent, then e-mail addresses in the
>  subjectAltName field are checked using Fingerpoint[1] to find
>  data about the owners of the addresses.

Yes. That seems like useful behaviour, even if you are going to end up having a lot of false positives for the moment, as very few sites implement this. Perhaps you should start with initially with a list of domain names that you publish on your web site that support it. The behavior can be that while that list exists, only domains listed there are checked. If that protocol is v. successful then all can be checked.

Good so from the cert you get the email, then you find some resource like a home page from the webfinger. You still have not tied the email to that user of the browser. For that to work, you need the home page to publish the public key that is in the certificate using rdfa or such.
In other words, it would be useful for the webfinger to return the WebId of the user, and from that allow one to find the public identity.

So there is a bit of work to do here to fill that out. 

Once you have that you have I think two pieces of info:
   1. you have the WebID of the user
   2. you also know his email address

So the WebFinger, webpointer technologies give us a way - I think - to verify an email address declaratively. (ie. without requiring the user to reply to an e-mail)

> This last point goes beyond our normal technique of validating
> certificates. I'd be interested to hear what people think about it. This
> provides the ability to use FOAF+SSL with certificates that have e-mail
> addresses but not URIs - this may be a useful fallback as OpenSSL is
> preconfigured to create certificates like this, so it's likely that
> there are a lot of existing certificates like this -- perhaps many from
> well-known certification authorities.
> ____
> 1. http://buzzword.org.uk/2009/fingerpoint/spec
> -- 
> Toby A Inkster
> <mailto:mail at tobyinkster.co.uk>
> <http://tobyinkster.co.uk>
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

More information about the foaf-protocols mailing list