- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Thu, 26 Jan 2012 11:01:10 +0100
- To: Henry Story <henry.story@bblfish.net>
- Cc: Joe Presbrey <presbrey@gmail.com>, Mischa Tuffield <mischa@mmt.me.uk>, public-webid@w3.org
On 26 January 2012 10:57, Henry Story <henry.story@bblfish.net> wrote: > > 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. > > Not all WebID certificates are self signed. They can be signed by the service that creates them. > 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. > > >> >> 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. > > I agree, removing the expired certificate PK is one thing to do. > ( But one might not necessarily want to remove the key either. We may want to have > a relation for ex keys, so that people who used keys to sign documents in the > past can still verify those signatures. e.g. > > <#me> cert:oldKey [ ...] > ) Perhaps validFrom and validTo would make more sense than oldKey as a predicate > > > > >> 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++. >> >> > > Social Web Architect > http://bblfish.net/ > >
Received on Thursday, 26 January 2012 10:01:44 UTC