Resend (again):
=============
All,
Finally found the email from Elaine Barker on the NIST deactivated key
state. It made things a little clearer for me but I see it as the
equivalent of what we call process only. Not sure how we want to
address this but I have a suggestion that may solve the entire issue by
making protect only, protect and process and process only policies
instead of states. It would require a revisit to section 4.4 but would
potentially clarify it.
Let
me know if I am off base here but the P1619.3 process only key state
means that the CU can access the key any time it wants to and is
required to support not using the key to encrypt with. Expired
is the state that disallows the key from general access unless an
exception is granted for its use (see Elaine’s response below) due to
regulatory or similar instances where data must be retained but not be
generally accessible. I would really like a specific use
case for each so that we could better define the differences in the
standard.
Bob
L.
Robert
A. (Bob) Lockhart
Sr.
Solutions Architect
Thales
Information Systems Security
From: Elaine
Barker [mailto:elaine.barker@xxxxxxxx]
Sent: Tuesday, November 06, 2007 5:41 AM
To: Robert Lockhart; William Barker; William Burr; William Polk;
Miles Smid
Cc: Larry Hofer; Jon Holdman
Subject: Re: Clarification of definition of deactivated key
Look at the deactivated state as the case
where a key is no longer used, for example, to encrypt data, but the
data needs to be kept around for a while (e.g., for x number of years
because of legal requirements). In this case, you would need to retain
the key to decrypt the data if it needs to be accessed some time in the
future.
Elaine
At 06:53 PM 11/5/2007, Robert Lockhart wrote:
All,
I am the editor of the IEEE P1619.3 Key Management Services work group
and have been tasked with asking for clarification on states and
transitions. I am not sure who is the correct person to answer this is
so I am asking all of you as the authors of SP800-57 Part 1 (March
2007).
During our meetings to determine specifics of the lifecycle of keys for
data at rest we have had some confusion on exactly what a deactivated
key is. The givens are that a device has rights to access the key, is
authenticated to the key management server (KM Server) and
communications has been established.
The following questions are based on your state model found in Section
7 of SP800-57 Part 1.
The first definition is that the key still exists but is not returned
to the cryptographic unit except under strict circumstances for
decryption use only.
The second is that the key is accessible by authorized cryptographic
units for decryption at any time until the key changes states to
destroyed.
If additional clarification of my question is required please feel free
to contact myself, Larry Hofer (Emulex) and/or John Holdman (Sun
Microsystems).
While I do not foresee additional questions, there may be more as we
look for guidance to creating a standard for key management of data at
rest.
Thank you in advance for your assistance,
Bob Lockhart
Robert A. (Bob) Lockhart Chief Systems Architect
NeoScale Systems, Inc. Enterprise Storage Security
1655 McCarthy Blvd., Milpitas, CA 95035
Elaine Barker
National Institute of Standards and Technology
100 Bureau Drive, Stop 8930
Gaithersburg, MD 20899-8930
301-975-2911