Re: Certificate Expiry

>>> On 26 Jan 2012, at 08:33, 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.

>> On 26 January 2012 10:57, Henry Story <henry.story@bblfish.net> wrote:
>>> Not all WebID certificates are self signed. They can be signed by the service that creates them.

So you agree then about not checking dates on self-signed certs.

>>> This is probably not a bad thing, as the service that creates them can then have it's own WebID,
>>> and would end up constituting an extra verification layer. There is no requirement on self signed
>>> certificates in WebID.

Yes, it is a bad thing. Asking services to sign users so you can trust
the X509 properties increases "total fail" significantly when the
service is compromised [1]. When starting from zero, there is no
reason to trust a stand-alone "service" WebID if you can't trust a
stand-alone "user" WebID, and therefore their respective assurances do
not compound. The only time I can see signed WebIDs being useful is if
you want a managed/corporate/closed WebID environment. Henry, please
help us stay free and open!

X509 and CAs are not the good parts of WebID we should be
exploring/extending. eg. SSH and GPG-generated keys are also great for
WebID, as proven by Melvin. At Web scale, its best to strive for
decentralization.

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

> On 26 Jan 2012, at 11:01, Melvin Carvalho wrote:
>> Perhaps validFrom and validTo would make more sense than oldKey as a predicate

I agree. Surely I meant: don't *yet* have schema for that :)

[1] http://tech.slashdot.org/story/11/10/28/1954201/four-cas-have-been-compromised-since-june