Hi Folks,
To try straightening out P1619.3 in my own mind, I've run through P1619.3/D4 and written down a 1-page summary of all the Objects, Policies and Operations. I will pass this summary by the Sun team and hopefully have feedback before next week's meeting. In particular, I'm trying to find out if this list is suitable for a storage encryption solution (with a bias towards tape drives).
If the rest of you get a chance, please pass this list by your teams to see if this would work in your storage encryption environment.
I may have also misunderstood some of these items. Check whether these are right...
Thanks!
-Matt
Key Management Objects- Key - A key blob (potentially wrapped) and its metadata
- Key Blob - A symmetric key, possibly wrapped, that the cryptographic unit can use
- Key_Template - Attributes and policies which may be inherited when creating a key
- ENDPOINT_TYPE - An object that describes the capabilities of a KM client or crypto unit
- REALM (optional) - Used to segment objects in separate administrative DNS domains
- PEP (Policy enforcement point / cryptographic unit) - A metadata object that describes the device that uses the key to encrypt data
- Client - an object that contains the credentials and capabilities of a KM client
- Capability - A string that describes a particular capability of an endpoint (either km client or CU)
- Data Sets - A manageable unit of encrypted data (e.g., range of sectors or records)
- Client Groups - A group of one or more client objects
- Key Groups - A group of one or more key objects
- (proposed) Credential object - An authentication object that show proof of knowledge of a password or of a private key, typically by responding to a random challenge.
Key Management Policies- Key Assignment Policy - logic to map keys to data sets and cryptographic algorithms
- Retention Policy - logic to determine which data is accessible to a client for how long
- Wrapping Policy - determines whether a key should be wrapped before sending to a client
- Audit Policy - determines the auditing requirements on keys and clients
- Access/Distribution Policy - determines which clients and servers have access to keys
- Caching Policy - Determines whether a client may cache a key and for how long
Key Management Operations- Register Endpoint - operation to register a KM client to a KM server
- Authenticate - The KM client or CU proves its identity to the KM server using certs or passwords
- Capability Negotiation - The KM client sends its capabilities to the KM server
-
Get Server Capabilities - The KM server selects capabilities from the list provided by the KM client
- Create/Generate Key - KM client passes Key_template to server and requests new key from the KM server
- Store Key - Push a key generated by the KM client into the KM server
- Get Key - Client requests an existing key from the KM server's key store
- Push Audit Message - The KM client pushes a secure audit message into the KM server or other auditing device
- Get Random Bytes - The KM server returns cryptographically secure random bytes to the KM client
- GetStatus [server initiated] - The KM server asynchronously requests status from the KM client
- UpdatePending [server initiated] - The KM server asynchronously notifies the KM client that the KM server has updated status
- GetUpdateList [Client initiated] - Returns a list of updates from the KM server to the KM client (issued by KM client in response to receiving an UpdatePending)
--
Thanks!
Matt Ball, IEEE P1619.x SISWG Chair
M.V. Ball Technical Consulting, Inc.
Phone: 303-469-2469, Cell: 303-717-2717
http://www.mvballtech.com
http://www.linkedin.com/in/matthewvball