Re: S/Mime signing with WebID and certificate expiration

On 01/10/2012 12: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
>
>
> 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.
>
I wouldn't do that. Safety of cryptography goes hand in hand with 
advances of computer science, as well as hardware efficiency. Whatever 
hash algorithm you use today in your certificate will almost certainly 
be obsolete within a time frame much shorter than 20 years. Just look at 
the evolution so far - remember how MD5 used to be the latest and 
greatest. I used to think I'd never need a PGP key longer than 1024 
bytes back in the 90s.

The WebID itself, being an (hopefully cool) URI should be as stable as 
possible, but the certs used for verification should not.

Same goes for email-signing certificates. When filtering mails, a 
receiving MTA would be caching the sponged data from the WebID 
dereference and match the signature hash already stored - otherwise 
checking a large number of incoming messages would become too expensive 
due to inevitable round-trip latency.

Cert expiry will act as a hard limit to that - no need to check 
anything. The sig's invalid and that's it. Bin it (or mark as fishy and 
deliver.)

The mail client (T-bird, etc.) would, of course, also mark it as invalid 
based on valid signature by trusted CA on an expired cert.

What Sebastian seems to attempt to describe here is a key revocation, 
rather than expiry mechanism. No? This would help the MTA mark emails as 
spoof, even when there's no connection to a (non-webid-aware) mail 
client to mark cert as revoked there.

Yrjänä

-- 
Mr. Yrjana Rankka        | ghard@openlinksw.com
Developer, Virtuoso Team | http://www.openlinksw.com
                          | Making Technology Work For You