Re: S/Mime signing with WebID and certificate expiration

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

http://www.cs.kent.ac.uk/pubs/2007/2791/index.html

A variation of this could be used by WebID

regards

David


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:01 UTC