Re: Certificate Expiry

On 26 January 2012 14:55, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> 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.

This is a great point there's 3 concepts I like to split out

authn
authz
discovery

They are like lego blocks that fit together to build a system

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

Received on Thursday, 26 January 2012 13:59:23 UTC