1 Key Management Interoperability Protocol (KMIP)

2 Agenda n The Need for Interoperable Key Management n KMIP Overview n KMIP Specification n KMIP Use Cases n KMIP Interoperability Demonstration

3 The Need for Interoperable Key Management n Today’s enterprises operate in increasingly complex, multi- vendor environments. n Enterprises need to deploy better encryption across the enterprise. n A key hurdle in IT managers deploying encryption is their ability to recover the encrypted data. n Today, many companies deploy separate encryption systems for different business uses – laptops, storage, databases and applications – resulting in: l Cumbersome, often manual efforts to manage encryption keys l Increased costs for IT l Challenges meeting audit and compliance requirements l Lost data

4 Enterprise Cryptographic Environments Key Management System Disk Arrays Backup Disk Backup Tape Backup System Collaboration & Content Mgmt Systems File Server Portals Production Database ReplicaStaging Enterprise Applications eCommerce Applications Business Analytics Dev/Test Obfuscation WANLANVPN Key Management System CRM Often, Each Cryptographic Environment Has Its Own Key Management System

5 Enterprise Cryptographic Environments Key Management System Disk Arrays Backup Disk Backup Tape Backup System Collaboration & Content Mgmt Systems File Server Portals Production Database ReplicaStaging Enterprise Applications eCommerce Applications Business Analytics Dev/Test Obfuscation WANLANVPN Key Management System CRM Often, Each Cryptographic Environment Has Its Own Protocol Disparate, Often Proprietary Protocols

6 KMIP Overview

7 What is KMIP The Key Management Interoperability Protocol (KMIP) enables key lifecycle management. KMIP supports legacy and new encryption applications, supporting symmetric keys, asymmetric keys, digital certificates, and other "shared secrets." KMIP offers developers templates to simplify the development and use of KMIP-enabled applications. KMIP defines the protocol for encryption client and key- management server communication. Key lifecycle operations supported include generation, submission, retrieval, and deletion of cryptographic keys. Vendors will deliver KMIP-enabled encryption applications that support communication with compatible KMIP key-management servers.

8 Enterprise Cryptographic Environments Enterprise Key Management Disk Arrays Backup Disk Backup Tape Backup System Collaboration & Content Mgmt Systems File Server Portals Production Database Replica Staging Key Management Interoperability Protocol Enterprise Applications eCommerce Applications Business Analytics Dev/Test Obfuscation WAN LAN VPN CRM KMIP: Single Protocol Supporting Enterprise Cryptographic Environments

9 Storage Array Tape Library SAN Application Server Application KMIP: Symmetric Encryption Keys Key Management Interoperability Protocol Enterprise Key Manager

10 KMIP: Asymmetric Keys Public Key KMIP

11 KMIP to Commercial Meter Utility KMIP: Digital Certificates KMIP to low-end Residential Meter KMIP to Industrial Meter

12 Encrypting Storage Host Enterprise Key *&^%$#&%$#$%*!^ Request Header Get Unique Identifier Symmetric Key Response Header Unique Identifier Key Value KMIP Request / Response Model Unencrypted data Encrypted data Name: XYZ SSN: Acct No: 45YT-658 Status: Gold

13 Encrypting Storage Host Enterprise Key *&^%$#&%$#$%*!^ Supporting Multiple Operations per Request Unencrypted data Encrypted data Name: XYZ SSN: Acct No: 45YT-658 Status: Gold Request Header LocateNameGet ID Placeholder Symmetric Key Response Header Unique Identifier Key Value

14 … TagLenValueTagLenValue … TagLenValueTagLenValue Messages in TTLV Format Type

15 Transport-Level Encoding Key Client Key Server API Internal representation Transport Internal representation Transport KMIP Encode KMIP Decode API KMIP

16 OASIS KMIP Technical Committee n OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society. n KMIP Technical Committee chartered in March 2009 l “The KMIP TC will develop specification(s) for the interoperability of Enterprise Key Management (EKM) services with EKM clients. The specifications will address anticipated customer requirements for key lifecycle management (generation, refresh, distribution, tracking of use, life-cycle policies including states, archive, and destruction), key sharing, and long-term availability of cryptographic objects of all types (public/private keys and certificates, symmetric keys, and other forms of “shared secrets”) and related areas.” KMIP TC IPR mode is Royalty Free on RAND

17 KMIP status n KMIP Technical Committee was established in OASIS in April 2009 l Submissions included at the time of TC creation included draft specification, usage guide and use cases l Initial membership included most significant vendors in cryptographic solutions and key management and has continued to grow. n KMIP V1.0 standard approved end-September 2010 l Revision of initial submissions April-October 2009 l First public review Nov/Dec 2009 l Revision of documents Jan-April 2010 l Second public review May/June l Approval of KMIP V1.0 docs as OASIS standard Sept 2010

18 KMIP V2.0 n Work currently underway for KMIP V2.0 l Committee Draft targeted for Q l Public review anticipated to start in Q l Final KMIP V2.0 standard expected early Q l Additions to protocol include additional attributes (permissions and groups) and operations (client registration) l May include enhancements related to server-to-server use cases. l Additions to profiles include asymmetric key use cases. l Additions to authentication methods under discussion, l Enhanced interoperability testing through cooperation with SNIA.

19 OASIS KMIP l Reading material: n n

20 KMIP Specification

21 Create Create Key Pair Register Re-key Derive Key Certify Re-certify Locate Check Get Get Attributes Get Attribute List Add Attribute Modify Attribute Delete Attribute Obtain Lease Get Usage Allocation Activate Revoke Destroy Archive Recover Validate Query Cancel Poll Notify Put Unique Identifier Name Object Type Cryptographic Algorithm Cryptographic Length Cryptographic Parameters Cryptographic Domain Parameters Certificate Type Certificate Identifier Certificate Issuer Certificate Subject Digest Operation Policy Name Cryptographic Usage Mask Lease Time Usage Limits State Initial Date Activation Date Process Start Date Protect Stop Date Deactivation Date Destroy Date Compromise Occurrence Date Compromise Date Revocation Reason Archive Date Object Group Link Application Specific ID Contact Information Last Change Date Custom Attribute Certificate Symmetric Key Public Key Private Key Split Key Template Policy Template Secret Data Opaque Object Managed ObjectsProtocol OperationsObject Attributes Key Block (for keys) or Value (for certificates) KMIP defines a set of Operations that apply to Managed Objects that consist of Attributes and possibly cryptographic material

22 KMIP Base Objects n Base Objects are: l Components of Managed Objects: n Attribute, identified by its Attribute Name n Key Block, containing the Key Value, either in the clear, either in raw format, or as a transparent structure or “wrapped” using Encrypt, MAC/Sign, or combinations thereof possibly together with some attribute values l Elements of protocol messages: n Credential, used in protocol messages l Parameters of operations: n Template-Attribute, containing template names and/or attribute values, used in operations

23 KMIP Managed Objects n Managed Cryptographic Objects l Certificate, with type and value l Symmetric Key, with Key Block l Public Key, with Key Block l Private Key, with Key Block l Split Key, with parts and Key Block l Secret Data, with type and Key Block n Managed Objects l Template and Policy Template: n Template has a subset of Attributes that indicate what an object created from such a template is n Policy Template has a subset of Attributes that indicate how an object created from such a template can be used n Note that (Policy) Templates have nothing except Attributes: for convenience these Attributes are included in the (Policy) Template structure too. l Opaque Object, without Key Block Certificate Symmetric Key Public Key Private Key Split Key Template Policy Template Secret Data Opaque Object Managed Objects Key Block (for keys) or value (for certificates)

24 KMIP Attributes n Attributes contain the “meta data” of a Managed Object l Its Unique Identifier, State, etc l Attributes can be searched with the Locate operation, as opposed to the content of the Managed Object n Setting/modifying/deleting Attributes l Only some of the Attributes are set with specific values at object creation, depending on the object type n For instance, the Certificate Type Attribute only exists for Certificate objects l Some Attributes are implicitly set by certain operations n Certificate Type is implicitly set by Register, Certify, and Re-certify l Client can set explicitly some of the Attributes n Certificate Type cannot be set by the client l Not all Attributes can be added, or subsequently modified or deleted once set n Certificate Type cannot added, modified or deleted l Some Attributes can have multiple values (or instances) organized with indices n For instance, a Symmetric Key object may belong to multiple groups, hence its Object Group Attribute will have multiple values

25 KMIP Attributes cont’d n 33 Attributes defined Unique Identifier Name Object Type Cryptographic Algorithm Cryptographic Length Cryptographic Parameters Cryptographic Domain Parameters Certificate Type Certificate Identifier Certificate Issuer Certificate Subject Digest Operation Policy Name Cryptographic Usage Mask Lease Time Usage Limits State Initial Date Activation Date Process Start Date Protect Stop Date Deactivation Date Destroy Date Compromise Occurrence Date Compromise Date Revocation Reason Archive Date Object Group Link Application Specific ID Contact Information Last Change Date Custom Attribute Describes what “is” the object Describes how to “use” the object Describes other features of the object

26 Key Lifecycle States and Transitions

27 Symmetric key: Activation Date Deactivation Date Protect Stop Date Process Start Date Protect Process Asymmetric key pair: Activation Date Deactivation Date Protect Stop Date = Protect Activation Date Deactivation Date Process Start Date = Process Public key for encryption Private key for digital signature Illustration of the Lifecycle Dates Private key for decryption Public key for digital signature

28 Symmetric Key 2 Symmetric Key 1 Symmetric Key 3 Secret Data Object 1Object 2 Derivation: Re-key or re-certify: Private Key Public Key Certificate 1 Certificate 3 Public/Private/Cert: Certificate 2 Object 3 Derived Key Base Object Replaced Object Replacement Object Public Key Private Key Certificate Public Key Certificate Illustrations of the Link Attribute

29 Client-to-server Operations n Operation consists of a request from client followed by server response n Multiple operations can be batched in a single request-response pair l ID Placeholder can be used to propagate the value of the object’s Unique Identifier among operations in the same batch l Can be used to implement atomicity n Requests may contain Template-Attribute structures with the desired values of certain attributes n Responses contain the attribute values that have been set differently than as requested by the client

30 Client-to-server Operations cont’d n 26 client-to-server operations defined Create Create Key Pair Register Re-key Derive Key Certify Re-certify Locate Check Get Get Attributes Get Attribute List Add Attribute Modify Attribute Delete Attribute Obtain Lease Get Usage Allocation Activate Revoke Destroy Archive Recover Validate (optional) Query Cancel (optional) Poll (optional) Notify (optional) Put (optional) Generate objects Set/get attributes Use the objects Support for asynchronous responses Support of optional operations Search and obtain objects Server-to-client operations

31 Server-to-client Operations n Unsolicited messages from the server to the client with the following operations: l Notify operation, used by server to inform client about attribute-value changes l Push operation, used by server to provide an object and attributes to client, indicating whether the new object is replacing an existing object or not l Batching can be used l Support is optional

32 Message Contents and Format n Protocol messages consist of requests and responses, each with a header and one or more batch items with operation payloads and message extensions n Header: l Protocol version l Maximum response size (optional, in request) l Time Stamp (optional in request, required in response) l Authentication (optional) l Asynchronous Indicator (optional, in request, no support for asynchronous response is default) l Asynchronous Correlation Value (optional, in response). Used later on for asynchronous polling l Result Status: Success, Pending, Undone, Failure (required, in response) l Result Reason (required in response if Failure, optional otherwise) l Result Message (optional, in response) l Batch Order Option (optional, in request, in-order processing is default). Support at server is optional l Batch Error Continuation Option: Undo, Stop, Continue. Stop (optional, in request, Stop is default). Support at server is optional l Batch Count n Batch Item: l Operation (enumeration) l Unique Message ID (required if more than one batch item in message) l Payload (the actual operation request or response) l Message Extension (optional, for vendor-specific extensions)

33 Message Encoding n Example of TTLV encoding of the Application Specific ID Attribute l Attribute identified by its name “Application Specific ID” l Shows value at index 2 TagTypeLengthValue AttributeStructure TagTypeLengthValue Attribute Name String “Application Specific ID” Attribute Index Integer42 Attribute Value Structure TagTypeLengthValue App. Name String “ssl” App. ID String “

34 Message Encoding cont’d n In a TTLV-encoded message, Attributes are identified either by tag value or by their name (see previous slide), depending on the context: l When the operation lists the attribute name among the objects part of the request/response (such as Unique Identifier), its tag is used in the encoded message l When the operation does not list the attribute name explicitly, but instead includes Template-Attribute (such as in the Create operation) or Attribute (such as in Add Attribute) objects as part of the request/response, its name is used in the encoded message tag … typelengthvalue operation A tagtypelengthvalue Unique Identifier f165d65-cbbd-4bd e0b390acf9 Get Unique identifier

35 Authentication n Authentication is external to the protocol n All servers should support at least l SSL/TLS n Authentication message field contains the Credential Base Object l Client or server certificate in the case of SSL/TLS *&^%$#&%$#$%*!^ @!$%!%!%!%^& *&^%$#&%$#$%*!^ Enterprise Key Manager Identity certificate SSL/TLS

36 KMIP Use Cases

37 KMIP Use Cases n Purpose: provide examples of message exchanges for common use cases n Categories l basic functionality (create, get, register, delete of sym. keys and templates) l life-cycle support (key states) l auditing and reporting l key exchange l asymmetric keys l key roll-over l archival l vendor-specific message extensions n Details of the message composition and TTLV encoding (encoded bytes included)

38 KMIP Use Cases: Example n Request containing a Get payload The operation (object type) and payload parameter Get (symmetric key) In: uuidKey Fields and structure of the message (length not shown) Tag: Request Message (0x ), Type: Structure (0x80), Data: Tag: Request Header (0x ), Type: Structure (0x80), Data: Tag: Protocol Version (0x ), Type: Structure (0x80), Data: Tag: Protocol Version Major (0x ), Type: Integer (0x01), Data: 0x (0) Tag: Protocol Version Minor (0x ), Type: Integer (0x01), Data: 0x (98) Tag: Batch Count (0x D), Type: Integer (0x01), Data: 0x (1) Tag: Batch Item (0x F), Type: Structure (0x80), Data: Tag: Operation (0x ), Type: Enumeration (0x04), Data: 0x A (Get) Tag: Request Payload (0x ), Type: Structure (0x80), Data: Tag: Unique Identifier (0x F), Type: Text String (0x06), Data: bf-4352-b1c4-9d48dac4b77d TTLV byte encoding of the message A D F A D F D D D D

39 KMIP Interoperability Demonstration

40 KMIP Interop Demo n Demonstrate protocol functionality using multiple independent implementations n Scenarios from the KMIP Use Cases document n Scenarios from Vendor Products

41 KMIP Interoperability Demo Interop Network Server hdd High Density Devices Client Server Client

42 KMIP Interop Demo Create / Destroy Register / Create / Get attributes / Destroy Create / Locate / Get / Destroy Dual client use-case, ID Placeholder linked Locate & Get batch Register / Destroy Secret Data Asynchronous Locate Revoke scenario Get usage allocation scenario Import of a Third-party Key Unrecognized Message Extension with Criticality Indicator false Unrecognized Message Extension with Criticality Indicator true Create a Key Pair Register Both Halves of a Key Pair

43 KMIP Interop Demo Create a Key, Re-key Existing Key Expired, Re-key with Same lifecycle Existing Key Compromised, Re-key with same lifecycle Create key, Re-key with new lifecycle Obtain Lease for Expired Key Create a Key, Archive and Recover it Credential, Operation Policy, Destroy Date Query, Maximum Response Size Additional Use Cases Asymmetric Register PKCS# Asymmetric Register Certificate Asymmetric Create / Re-Key Asymmetric Register / Certify Create / Destroy

44 Use Case (1/3) n The client asks the server to create a 128-bit symmetric key, using the AES algorithm, to be used for encryption and decryption n After the key has been created, the client asks the server to destroy the created key

45 Use Case (2/3) n Create-request, Attributes: { Algorithm=AES, Length=128, Usage Mask=encrypt&decrypt } n Create-response: Success, Unique Identifier of created key Client Server

46 Use Case (3/3) n Destroy-request, Unique Identifier of previously created key n Destroy-response: Success, Unique Identifier of destroyed key

47 Use Case (1/4) n The client registers a template with attributes n The client asks the server to create a symmetric key with the attributes specified in the previously registered template n The client retrieves a subset of the attributes of the key to verify they were set according to the template n Note: Operations already shown previous are not illustrated

48 Use Case (2/4) n Register-request, ObjectType=Template, Attributes (e.g.): { Name=Template1, ObjectGroup=Group1 } n Register-response: Success, Unique Identifier of registered template

49 Use Case (3/4) n Create-request, TemplateName=Template1 n Create-response: Success, Unique Identifier of created key

50 Use Case (4/4) n Get Attributes-request, Attribute Names: { ObjectGroup, AppSpecificInfo, ContactInfo, x-Purpose } n Get Attributes-response: Success, Attributes { ObjectGroup=Group1 etc. } ?

51 Use Case (1/3) n The client asks the server to create a key and specifies a Name attribute value n The client then performs a Locate operation, supplying the Name, to which the server responds with the Unique Identifier of the created key n The client retrieves the created key using its Unique Identifier

52 Use Case (2/3) n Locate-request, Attribute: { Name=Key1 } n Locate-response: Success, Unique Identifier of created key Previously created Key with Name attribute set

53 Use Case (3/3) n Get-request, Unique Identifier of previously created key n Get-response: Success, key material of the previously created key

54 Use Case n This use-case has two clients performing operations on the same key. n The first client registers a template and creates a symmetric key using that template. n The second client then does a batched Locate and Get using the ID Placeholder to retrieve the key.

55 Use Case (cont) n The second client thereafter performs a number of operations on the key before the first client finally destroys the key and the template. n The first client also tries to Get the key and the template after they have been destroyed, but the Get operation fails in both cases.

56 Use Case n In this use-case the client issues a Register request containing a Secret Data object, whereby the server registers the object and returns the Unique Identifier. n To clean up, the client then performs a Destroy operation to destroy the object.

57 Use Case 3.2 n This use-case tests the asynchronous capabilities of KMIP using the Locate operation. n A key is created and then a Locate request is sent containing the Name of the created key and with the message header Asynchronous Indicator-field set to True.

58 Use Case 3.2 (cont) n If the server returns an asynchronous response to the Locate, the client then polls the server until the operation is ready. n If the server responded asynchronously, a subsequent Locate operation that is also handled asynchronously is then Cancelled, before the key is finally destroyed.

59 Use Case 4.1 (1/4) n The client asks the server to create a key n The client gets the State attribute to confirm that the key is initially in the Pre- Active state n The client performs an Activate operation to change the state to Active n The client performs a Revoke operation to change the state to Compromised

60 Use Case 4.1 (2/4) n Get Attributes-request: Unique Identifier of key, Attribute Name: { State } n Get Attributes-response: Success, Unique Identifier of key, State=Pre-Active ? Previously created key in the Pre-Active state

61 Use Case 4.1 (3/4) n Activate-request: Unique Identifier of key n Activate-response: Success, Unique Identifier of activated key

62 Use Case 4.1 (4/4) n Revoke-request: Unique Identifier of key, Revocation Reason=Compromised n Revoke-response: Success, Unique Identifier of revoked key

63 Use Case 5.1 (1/4) n The client asks the server to create a key, activates it and sets a certain amount of Usage Allocation (1000 MB) n The client gets some Usage Allocation so that it can use the key e.g. for encrypting data n Once it has been used up, the client requests some more usage allocation n When the usage allocation has been used up, the key cannot be used for encryption anymore

64 Use Case 5.1 (2/4) n Get Usage Allocation-request: Unique Identifier of key, ByteCount=500 n Get Usage Allocation-response: Success, Unique Identifier of key Usage allocation

65 Use Case 5.1 (3/4) n Get Usage Allocation-request: Unique Identifier of key, ByteCount=500 n Get Usage Allocation-response: Success, Unique Identifier of key Usage allocation (usage allocation is used up)

66 Use Case 5.1 (4/4) n Get Usage Allocation-request: Unique Identifier of key, ByteCount=500 n Get Usage Allocation-response: Operation Failed, Usage Allocation requested could not be granted Usage allocation (usage allocation is used up)

67 Use Case 6.1 n This use-case tests the import of a foreign key using the Register operation. n To validate that the registered key is treated the same as a locally created key, an attribute is added to the key and then modified. n Finally, the key is destroyed.

68 Use Case 7.1 n A create request is issued and the request contains a Message Extension with the Criticality Indicator set to false. n The server does not understand the extension, but since it is non-critical, the create request is processed normally. n Subsequently, the created key is deleted.

69 Use Case 7.2 n A create request is issued and the request contains a Message Extension with the Criticality Indicator set to true. n The server does not understand the extension, and since it is critical, the create request fails and an error is returned.

70 Use Case 8.1 n Create a new private/public key pair. n Make sure they are linked correctly by issuing Locate commands with the assigned Unique Identifiers. n Finally delete both key halves.

71 Use Case 8.2 n Register a private key and a public key and set the Link attribute to point to each other. n Verify the links were set correctly by locating the keys based on the link attributes n Delete both objects.

72 Use Case 9.1 n Create a symmetric key with a specific name, and then use Locate to find the key. n After using Re-key to create a new key, verify that the name was removed from the existing key and copied to the new key. Also verify that the key material for the old key is still retrievable. n To clean up, both keys are deleted.

73 Use Case 9.2 n Create a new symmetric key. Then add the Activation Date and Deactivation Date attributes based on the timestamp in the response to the Create request. n The Activation Date is set to a time in the past and the Deactivation Date to a time in the near future.

74 Use Case 9.2 (cont) n Repeated Get Attribute calls are performed to verify that the state is first “Active”, then subsequently “Deactivated”. n Then issue a Re-key request, including an Activation Date attribute with the value set to the previously specified Deactivation Date of the existing key.

75 Use Case 9.2 (cont) n Verify from the response that the Activation Date and Deactivation Date attributes were set correctly (if they are not returned, issue a Get Attribute request). n Do a Get Attribute operation to verify that the state of the new key is “Active”. n To clean up, both keys are deleted.

76 Use Case 9.3 n Create a new symmetric key with the Activation Date in the past. n Do a Get Attribute operation on the State attribute to verify the key is “Active”. n Then revoke the key as compromised, verify that the state has changed to “Compromised”.

77 Use Case 9.3 (cont) n Create a replacement key using Re- key with the offset set to ‘0’ to indicate that the times are to be copied from the existing key. n Do a Get Attribute operation to verify that the state of the new key is “Active”. n To clean up, both keys are deleted.

78 Use Case 9.4 n Create a symmetric key with a specific name, then use Locate to find the key. n After using Re-key to create a new key, verify that the name was removed from the existing key and copied to the new key. n To clean up, both keys are deleted.

79 Use Case 9.5 n Create a symmetric key with a specific name and obtain a lease. Revoke the key with state “Compromised” and re-key the key. n Try to obtain a lease on the old key which fails. n Locate the new key with the original name. n Get the new key and obtain a lease.

80 Use Case 10.1 n Create a symmetric key with a specified name, then use Locate to find the key and get the key. n Archive the key (asynchronous operation, use Poll until it completes) and use Get and Locate on it, but both fail.

81 Use Case 10.1 (cont) n Add the Storage Status Mask to the Locate-command, indicating to the server to search in both online and archived storage. n The Locate finds the key. n Recover the key from the archive (also asynchronous), both Locate and Get succeed.

82 Use Case 11.1 n Pass a Credential object in the message header in all requests for identification purposes n Create a symmetric key and set the Operation Policy Name attribute to “default”.

83 Use Case 11.1 (cont) n Using another Credential, attempt to perform a Get operation batched with a Get Attribute List on the created symmetric key - both these request SHALL fail, as Batch Error Continuation Option set to “Continue”, the client gets both response payloads. n Using the initially used Credential, destroy the object and get the Destroy Date attribute.

84 Use Case 12.1 n Perform a Query operation, querying the Operations and Objects supported by the server, with a restriction on the Maximum Response Size set in the request header. n Since the resulting Query response is too big, an error is returned.

85 Use Case 12.1 n Increase the Maximum Response Size, resubmit the Query request, and get a successful response.

86 Use Case 13.1 n Register a public/private RSA key pair n Otherwise the same as 8.2, but with PKCS #1 format and additional Get operations to verify keys were registered correctly

87 Use Case 13.2 n Register a public/private RSA key pair and associated X.509 certificate n Set links between key pair and certificate n Verify certificate attributes are set correctly

88 Use Case 13.3 n Create a public/private RSA key pair, get the keys in PKCS #1 format n Re-key key pair (proposed v2.0 operation) n Locate on name to make sure Name attribute was transferred to new keys n Get new keys in Transparent RSA key format n Get link attributes

89 Use Case 13.4 n Register a public/private RSA key pair in PKCS #1 format n Set links n Certify the public key using PKCS #10 CSR n Get certificate (X.509 format), n Get certificate attributes n Get links

90 Conclusion

91 Enterprise Cryptographic Environments Enterprise Key Management System Disk Arrays Backup Disk Backup Tape Backup System Collaboration & Content Mgmt Systems File Server Portals Production Database ReplicaStaging Key Management Interoperability Protocol Enterprise Applications eCommerce Applications Business Analytics Dev/Test Obfuscation WAN LAN VPN CRM KMIP: enabling enterprise key management through standard protocol

92 Q&A