W3C home > Mailing lists > Public > public-xg-webid@w3.org > October 2012

Re: S/Mime signing with WebID and certificate expiration

From: David Chadwick <d.w.chadwick@kent.ac.uk>
Date: Mon, 01 Oct 2012 12:16:29 +0100
Message-ID: <50697B8D.8030301@kent.ac.uk>
To: Melvin Carvalho <melvincarvalho@gmail.com>
CC: Sebastian Trueg <trueg@openlinksw.com>, public-webid@w3.org, public-xg-webid@w3.org
Several years ago we published an alternative option, which was to 
include a revocation URL inside the certificate along with the URL of 
where the certificate could be obtained from. Only one of these URLs 
will ever be active (the Internet acts as a state machine) as the 
certificate either exists or is revoked. We did have a PKIX draft for 
it, but it never progressed to standard. However the scheme is described 
in this paper


A variation of this could be used by WebID



On 01/10/2012 11:01, Melvin Carvalho wrote:
> On 1 October 2012 11:47, Sebastian Trueg <trueg@openlinksw.com
> <mailto: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 <mailto:trueg@openlinkws.com>
>     http://openlinksw.com
>     http://trueg.wordpress.com
>     http://www.linkedin.com/in/__trueg <http://www.linkedin.com/in/trueg>
Received on Monday, 1 October 2012 11:17:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:56 UTC