Re: Certificate Expiry

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.

-- 

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