- From: Henry Story <henry.story@bblfish.net>
- Date: Thu, 26 Jan 2012 13:17:41 +0100
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-webid@w3.org
On 26 Jan 2012, at 12:59, Kingsley Idehen wrote: > On 1/26/12 2:33 AM, Joe Presbrey wrote: >> The notion of self-signed WebID certificates (securely) expiring is invalid and quite easily misunderstood. There are no assurances for start/end dates (or any other properties, eg. WebID URI!) within the certificate itself. >> >> This is precisely why we resolve the WebID URI: to check if the claims in the certificate are true. We could also check the URI/LD to see if dates match, but we don't currently have schema for that, and why bother? >> >> Remove the "expired" certificate's public key from your FOAF/LinkedData if you want to deactivate it. Otherwise, >> >> re-self-sign: >> https://gist.github.com/1653329 >> >> You won't need to update your FOAF/LD as your Public Key will not change. >> >> >> On Wed, 25 Jan 2012, Mischa Tuffield wrote: >>> Mischa *needs to generate a new cert I guess $todoList++. >> >> >> > +1 > > I've been mauling over this a bit and I don't think it really fits into the Authentication realm. This is an Authorization realm matter. Basically, one should be able to construct a resource access policy (via ACL) that determines how certificate expiration is to be handled. ACL, stands for Access Control Lists, that is a document, such as the one developed by the Web Access Control ontology [1], which specifies which agents can have access to which resources. If you don't know what agent you have on the other end, you can't determine what rule to apply. So before applying ACLs we need to authenticate. If the server receives a certificate that is expired then you are now ignoring the first information that is reaching your server: the one in the certificate. As such you are ignoring what the signer of the certificate released, and one would think that given that the person is using that Issuer, even if you don't know who that is, that should have a little weight in the process. Essentially the issuer would be saying: after that date don't count on me to vouch for this certificate - i.e.: it could have fallen into the wrong hands. So at the minimum you should be aware of that as a warning signal. But of course nobody has to listen to warning signals. One can override them. But not even noticing that these are warning signals would show someone to be an incompetent guard. Henry [1] http://www.w3.org/wiki/WebAccessControl > > -- > > Regards, > > Kingsley Idehen > Founder& CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > > > Social Web Architect http://bblfish.net/
Received on Thursday, 26 January 2012 12:18:12 UTC