Re: Certificate Expiry

On 1/26/12 7:17 AM, Henry Story wrote:
> 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.

I understand that, and my position remains. Please don't assume that one 
ontology defines the realm of ACLs, please don't go down that path.

When I say ACL I absolutely do not mean the Access Control Ontology.

I mean, anyone is in a position to construct a resource access policy 
based on the credentials presented at resource access time. Thus, if I 
choose, I can decide to not accept identity associated with an expired 
certificate.

> If the server receives a certificate that is expired then you are now ignoring the first information that is reaching your server:

No I am not. The certificate is just carrying a set of claims. I decide 
what to do with those claims.

> 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

I've done policy based data access for 20+ years. Its how I built my 
company. The rules for policy based access must be left to the publisher 
of a given resource. The x.509 certificate is just a bunch of claims, 
and that's basically it. What WebID does is introduce loose coupling and 
machine accessible and comprehensible semantics. This provides a very 
rich substrate for fine-grained access control policies.

Again, ACL != a single ACL ontology (which defines a specific world 
view). It is much more than that.

>
>> -- 
>>
>> 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/
>
>
>


-- 

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