Re: [ekmi] Re: [P1619-3] OASIS EKMI Article in InformationWeek

[Arshad Noor <arshad.noor@strongauth.com>]

Legacy data issues are always a legitimate concern in any environment,
Allen.  However, I believe that the problem will be addressed rather
differently than in the way you suggest.  Here's an analogy of how I
think it will happen:

Currently, there is a recommendation from NIST that all software/data
that use SHA-1 should migrate away from this digest by the end of 2010.
How do you think most people will accomplish this?  They will likely
modify their applications/data to use one of the newer Suite-B message
digests rather than preserve the old SHA-1 data and perennially have
doubts about the integrity and veracity of that data because of the
de-listed hash.

Similarly, an application that uses 3DES or AES today will continue to
use it until new recommendations are made in the crypto community.
When the recommendations are made, there will be a transition period
during which application developers and security officers will have
the time to migrate their data and infrastructure to use the newer
algorithms.  When done, they will turn off the older algorithms by
not making them available in any KeyUsePolicy (in an SKMS).  However,
an SKMS, for the duration of the transition, will continue to support
both sets of algorithms, digests, etc. until the last KUP using the
older algorithms is turned off.

Not only does this obviate the legacy issue, but more importantly,
it eliminates the concern that there is ciphertext lying around in
the company's infrastructure that may be encrypted with a "weak" or
"broken" algorithm.  That will be a bigger danger for companies
trying to manage risk in this new world of IT regulations.

Arshad Noor
StrongAuth, Inc.


Allen wrote:

> I'm not at all certain that there might not be one legacy use for 
> hardware level storage - archives of historical keys, data and such for 
> later recovery that is software and software version agnostic.
> 
> If the encryption is done with V1.1 and several years later V3.7 is the 
> version that is in use, how do you recover data from an application that 
> used V1.1? One would not want to retain the weaknesses of V1.1 in V3.7 
> in order to recover a V1.1 set of data as that would duplicate the 
> LANMAN/NTLM problem.
> 
> I think careful thought about the legacy issue is in order and, indeed, 
> it may be easiest solved with a low level hardware solution that does 
> not change until the data is migrated off the device.