Re: Expiry time in Data Model

On 21/05/2016 23:22, Dave Longley wrote:
> 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.

even if they are now forged and fake :-)

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

I agree, and I think you misunderstood me as well. The expiry date is
likely to be chosen by the issuer depending upon the risk and business
reasons, and not on the crypto. I was not saying that the expiry date
would be based on the crypto. Rather, having an infinitely valid
credential is bad because of the inherent weakness of the cryptography,
that is the point I was making. Furthermore it becomes costly to have to
keep revocation information until infinity if the credentials are valid
until infinity. This is why I believe we should mandate the field and
not allow infinity.

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

But this does not happen in reality. We still have root CAs in browsers
that have broken cypto, and they and their subordinate CAs are still
trusted. I am not aware of browsers even warning users about this. (And
in this case even having an expiry time has not saved them, as it was
set too far in the future :-(

regards

David

Received on Sunday, 22 May 2016 08:06:55 UTC