[foaf-protocols] inducing IE to treat its client cert selector much like an infocard selector

[Story Henry]

On 27 Nov 2009, at 16:25, Peter Williams wrote:

> [Peter Williams] adds comments below
> 
>> The properties of one foaf card's document (e.g. its cache timeout
> signaled
>> via HTTP) now controls multiple ssl connections.
> 
> you mean that if someone removes the public key from the foaf file, the
> certificates should be invalidated, and so the connections should no longer
> be allowed by the server.
> 
> [Peter Williams] Yes - but its more general than that, I feel. If the very
> server-side cache entry of the user's foaf file (as container for the
> PubKeys and Groups) itself expires, certain current SSL connections (and
> their supporting TCP connections) are dropped by the server. 

Why? Why not fetch the foaf file again. You could even do a HEAD, to see if the etag had changed I think.

Then depending on what the user is doing you can drop him or not. Depending...

> This is analogous to military PKI for military https ciphersuites, in which
> a long lived SSL connection is dropped when actual time is post the
> not-after time of the client certificate that contributed keying material to
> the SSL master secret from which the particular SSL connection's keys were
> derived.

The X509 certificate comes with a validity time interval. So certainly when that interval is over the server should ask the client for a new certificate.

In summary:
  - the X509 certificate comes from the client, so if its validity expires, one should fetch a new one from the client
  - if the the time is past the cached foaf file HTTP EXPIRES header date, then the server should fetch the foaf file again, not break the connection with the client - not automatically at least.


> In foaf+ssl we don't have "expiry" time in foaf cards. We can borrow a time
> model from the HTTP document caching world, however, keeping foaf+ssl's
> security model "close to the web".

yes, the Expires header I think is meant for this
http://tools.ietf.org/html/rfc2616#page-127

> 
> [cut] 
> 
> 
> 
> Btw, I think in discussing this it is important to distinguish the different
> roles IIS can appear in:
>  1. as serving foaf for the End User
>  2. as the relying party to which the End USer is connecting
>  2.1 it's tracking of the foaf file in 1
>  2.2 it's keeping the SSL connection with the End Users' client renewed
>  3. the end user's client (Internet Explorer, Firefox, Safari, Opera) and
> their behaviour as to how they ask the client for a certificate
> 
> 
> [Peter Williams] 2.1 is the critical observation I believe. It's the crux of
> the "foaf+ssl" validity model, where invalidity induces various security
> actions (such as 2.2, and 3...). Invalidity is something that the SSL
> component of the foaf+ssl engine in the NT kernel would have to be
> constantly testing.

Not sure why this is an NT kernel issue. (other than that Microsoft likes to put everything in the kernel in order to argue that it is part of the OS.)

Henry