W3C home > Mailing lists > Public > public-credentials@w3.org > May 2016

Re: Expiry time in Data Model

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Sat, 21 May 2016 18:22:56 -0400
To: David Chadwick <d.w.chadwick@kent.ac.uk>, public-credentials@w3.org
Message-ID: <5740DFC0.5070902@digitalbazaar.com>
On 05/21/2016 02:44 PM, David Chadwick wrote:
> 
> 
> On 21/05/2016 12:56, Victoriano Giralt wrote:
>> On 20/05/16 22:35, David Chadwick wrote:
>>>> what is an example of a credential that's irrevocable?
>>> 
>>> Any short lived one, where the time/overhead of revocation is
>>> comparable with the lifetime
>> 
>> Stupid question: wouldn't a birth certificate be an irrevocable 
>> credential? It is a fact of life that any person is born, you can
>> (and will) die, but your birth a fact that existed in a given point
>> in time.
>> 
> 
> You are mixing up the attribute/claim, date of birth (or similar)
> which lasts forever, and the credential, which is a cryptographic
> digital representation of it. This has to have an expiry time due to
> the inherent weakness of the crypto.

I do think we should recommend expiration dates as a best practice, but
I'm not convinced that they should be made mandatory because of the
inherent weakness of crypto -- or that they should even be derived on
that basis. I don't think that's the right way to achieve what we want.

I think it's too much to ask issuers to guess when certain crypto
methods may no longer be suitable by encoding this as an expiration date
on their issued credentials. I also think it's too much to force a short
expiration date on all credentials.

First, many issuers will lack the appropriate expertise to make an
educated guess as to when credentials should expire on the basis of
crypto method lifetime. Second, even if they are following good advice
from the crypto community, the experts can still guess wrong. If they
guess too soon then there is unnecessary overhead in reissuing
credentials. If they guess too late, then credentials that were
protected with weak or broken cryptography will continue to verify.
Third, issuers will likely tend to choose their expiration dates on the
basis of the nature of the claims they are making rather than the
underlying crypto protecting the integrity of those claims. The
difference you highlight is likely to be misunderstood.

Instead, this should be enforced by verification tools' inspection of
particular crypto methods, regardless of expiration dates. Whenever a
crypto method is declared weak or broken, it should be phased out by
verification tools. That way, it won't matter whether the expiration
date is present or not -- the appropriate warnings or errors will be
issued on the basis of the known status of those crypto methods.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
Received on Saturday, 21 May 2016 22:23:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:29 UTC