Re: S/Mime signing with WebID and certificate expiration

This is part of ISSUE-22: Key Pair Revocation / WebID reset
But I think we might have dealt with that issue: just remove the cert:key relation to that public key.
(Need to look at the spec)

I opened a new ISSUE-67: Ontology for expired keys
https://www.w3.org/2005/Incubator/webid/track/issues/67


On 1 Oct 2012, at 12:01, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 
> 
> 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 ] .

That won't work as is, because it will require a cert:RSAPublicKey to have an expiration date. If it has one
then it could also be used in

:me cert:key [  a cert:RSAPublicKey, cert:ExpiredKey;
    rdfs:label "Key from back when" ;
    cert:modulus "...." ;
    cert:exponent 65537 ;
    cert:expired "2012-06-12T12:42"^^xsd:datetime 
] .

If we have that then we need to change all implementations to check for expiry time on cert:key too.
This is because it brings up the question of what it  means when the dates are missing from a key. Here is the reasoning:

Since RDF is monotonic - ie.  adding new relations to a document should not remove consequences you
could arrive at without those relations - you could not come to the conclusion that a key was valid if you
did not have that information.


You need therfore to have a new type of object cert:DatedKey. This would more likely have to have a relation such as

:me cert:expiredKey [ a xxx:DatedObject;
    rdfs:label "Key from back when" ;
     cert:expired "2012-06-12T12:42"^^xsd:datetime 
    cert:about [ a  cert:RSAPublicKey; ... ]
   ]

Perhaps there are ontologies we could re-use for this?   

Henry

> 
> (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
> 
> 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
> 
> 

Social Web Architect
http://bblfish.net/