Re: S/Mime signing with WebID and certificate expiration

If I understand correctly this would involve changing certificates. In 
other words it is not a backwards-compatible resolution, is it?

On 10/01/2012 01:16 PM, David Chadwick wrote:
> 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>
>>
>>
>
>


-- 
Sebastian Trueg
Technical Consultant
OpenLink Software
trueg@openlinkws.com
http://openlinksw.com
http://trueg.wordpress.com
http://www.linkedin.com/in/trueg