On 1 October 2012 11:47, Sebastian Trueg <trueg@openlinksw.com> wrote:
> When I was introduced to WebID in my head it was mostly about
> authentication-related scenarios, situations in which one needs to
> authenticate to get access to something. Let's call them "immediate
> identity-proof" scenarios.
> In these situations a compromised private key is no big deal: you simply
> remove the public key from your profile and you are safe.
>
> However, when it comes to email-signing this is not practical anymore. If
> you would do that then suddenly all the emails you sent before the change
> of the key will show up as unverified in the recipients' inboxes.
>
> I briefly discussed this problem with Henry who told me that it had been
> discussed before[1]. In the light of us all signing our emails with
> WebID-enabled certificates I would like to bring this up again, find a
> solution, and start implementing it.
>
> The simplest way to go AFAICS would be to introduce a new property to add
> "expired" keys to a profile. This would retain compatibility with existing
> implementations which are mostly about authentication and do not need to be
> bothered with this extension.
>
> To get the ball rolling let me throw some Turtle at you:
>
> <#me> cert:expiredKey [
> a cert:RSAPublicKey, cert:ExpiredKey;
> rdfs:label "Key from back when" ;
> cert:modulus "...." ;
> cert:exponent 65537 ;
> cert:expired "2012-06-12T12:42"^^xsd:**datetime ] .
>
> (IMHO it would be much cleaner to use the good old cert:key property and
> just make the key another type but that might break implementations.)
>
> Using this extension email clients could still verify old emails even
> though the key has been compromised in the meantime.
>
> Regards,
> Sebastian
>
> [1] http://lists.w3.org/Archives/**Public/public-webid/2012Jan/**0031.html<http://lists.w3.org/Archives/Public/public-webid/2012Jan/0031.html>
>
I wonder if "Cool URIs dont change" is related to this.
IE cool keys dont change?
I have set my key for 100 years expiry which I will try to take care of.
Of course you can have multiple keys and throw away keys.
Perhaps we should have a preferred or canonical key much like we have a
preferredURI
... just thinking out loud ...
>
> --
> Sebastian Trueg
> Technical Consultant
> OpenLink Software
> trueg@openlinkws.com
> http://openlinksw.com
> http://trueg.wordpress.com
> http://www.linkedin.com/in/**trueg <http://www.linkedin.com/in/trueg>
>
>