← Prev in month ← Prev in thread
Next in thread → Next in month →

Cryptsoft KMIP Server Update

From
Tim Hudson
Date
2011-02-01T13:09:00+00:00
ID
Thread
Cryptsoft KMIP Server Update
The Cryptsoft public interop server has been updated to include support for the entire range of use cases contained in the 1.0 document. The feature set also includes the first two of the four asymmetric use cases as per previous releases.  Attached is the readme.txt outlining the behaviour of the interop server.  There are a number of areas currently under discussion in terms of what the correct behaviour and these are noted in the readme.txt file.  More updates are planned prior to the feature freeze for the RSA interop this Wednesday.  Thanks, Tim
The Cryptsoft KMIP server supports the following use cases:  3.1.1	- Create / Destroy 3.1.2 	- Register / Create / Get attributes / Destroy 3.1.3
- Create / Locate / Get / Destroy 3.1.4 	- Dual client use-case, ID Placeholder linked Locate & Get batch 3.1.5 	- Register / Destroy Secret Data 3.2 	- Asynchronous Locate 4.1 	- Revoke scenario 5.1 	- Get usage allocation scenario 6.1 	- Import of a Third-party Key 7.1 	- Unrecognized Message Extension with Criticality Indicator false 7.2 	- Unrecognized Message Extension with Criticality Indicator true 8.1	- Create a Key Pair 8.2 	- Register Both Halves of a Key Pair 9.1 	- Create a Key, Re-key 9.2 	- Existing Key Expired, Re-key with Same lifecycle 9.3 	- Existing Key Compromised, Re-key with same lifecycle 9.4
- Create key, Re-key with new lifecycle 9.5
- Obtain Lease for Expired Key 10.1
- Create a Key, Archive and Recover it 11.1	- Credential, Operation Policy, Destroy Date 12.1	- Query, Maximum Response Size  And the following post-1.0 defined use cases shared on the kmip-interop mailing list.  13.1 	- Asymmetric Register PKCS#1 13.2 	- Asymmetric Register Certificate  Not yet supported:  13.3
- Asymmetric Create / Re-Key 13.4
- Asymmetric Register / Certify  The server should be producing responses in conformance with the use case document for version 1.0 of KMIP (effectively the 20-May-2010 version).  An HTML form of each of the use cases is available at
http://interop.cryptsoft.com/kmip_uc/
The Cryptsoft KMIP server has the following behaviours:  - the QUERY response returns ERROR with BATCH_ITEM and BATCH_COUNT in 12.1.0  - the QUERY response contains only those items supported in 12.1.1  - the OPERATION value is returned for requests which fail (which is
not mandatory in the current wording of the specification but matches
the behaviour in the use cases) - e.g. 3.1.4.9  - the ADD_ATTRIBUTE step in 5.1.2 does not return USAGE_LIMITS_COUNT as
it was not supplied by the client. USAGE_LIMITS_COUNT is created only
when required (if it does not exist) in GET_USAGE_ALLOCATION.  - CREDENTIAL checks are performed prior to processing any BATCH items
and any credential check failure will result in an error reported
on the first batch item and the remainder of the batch will be
ignored (i.e. not processed). See UC 11.1.2.0 OUT as use case 11.1
expects each batch item to perform the credential check and report
results individually. The specification does not detail how
a KMIP server is meant to handle this situation.  - DESTROY is actually destructive. You cannot return any details for an
object after a DESTROY has been performed. (See UC 11.1 which is
not supported as it requests the "Destroy Date" after a DESTROY
operation has been performed). This behaviour is allowed by the
specification  - LEASE_TIME is an attribute for all objects and is returned in the
various GET_ATTRIBUTES lists. The use case document currently does
not show this attribute being returned.  - INTERVAL values are unsigned. The use case document currently shows
a negative INTERVAL in UC 9.4 TIME 4.
The server supports multiple clients connecting simultaneously and also will process multiple interactions on the one connection.  A separate interop server has been setup for each vendor perfoming interop testing so that testing doesn't not get intermixed.  There are certificate for use in PEM (.pem) and PKCS12 (.pfx) and Java Key Store (.jks) format the appropriate client certificate to use. The CA used to sign the server certificate is in CA.pem and trustStore.jks should your environment require it to be installed.  The interop server currently ignores the details in the client certificate  provided for mutual authentication of the TLS connection.  The password for all the JKS and PKCS12 files is the typical non-password of 'password'.  Notes:  - BATCH_ERROR_CONTINUATION_OPTION_UNDO is not supported and an error
will be reported if selected (as allowed in the specification).  - POLL and CANCEL are simulated in that the action is always performed
and simply delayed in being reported.
i.e. CANCEL will report KMIP_CANCELLATION_RESULT_COMPLETED  - MESSAGE_EXTENSION values are ignored (unless CRITICALITY_INDICATOR is
set to true and then an error is returned).  - ADD_ATTRIBUTE with USAGE_LIMITS excluding USAGE_LIMITS_COUNT does not
spontaneously create USAGE_LIMITS_COUNT or return it in the ADD_ATTRIBUTE
response. (See UC 5.1.2 OUT)  - ADD_ATTRIBUTE with ACTIVATION_DATE in the past automatically updates
the STATE from PRE_ACTIVE to ACTIVE. (See UG 5.1.1 IN)  - The Cryptsoft server does not force NAME attributes to be unique
within a given KMIP server. (See SPEC 3.2 for this requirement)
Implementation Limitations:  - LOCATE does not support wild-cards or regular expressions
note: this is marked as optional in the specification (MAY)  - LOCATE does not support USAGE_ALLOCATION matching  - LOCATE does not support partial structure matching  - CHECK and GET_USAGE_ALLOCATION do not implement LEASE_TIME checking
and silently ignore (report success) for requests containing LEASE_TIME.  - MODIFY_ATTRIBUTE and DELETE_ATTRIBUTE perform no checks for whether or
not the opperation should be allowed. All operations on existing attributes
are simply processed as requested.  - Multiple instances of ATTRIBUTES are not handled correctly in GET_ATTRIBUTES
and a list is returned without INDEX values  Conformance:  - SPEC
12.1	KMIP Server - PROFILE  4.1	Secret Data KMIP Profile - PROFILE  4.2	Basic Symmetric Key Store and Server KMIP Profile - PROFILE  4.3	Basic Symmetric Key Foundry and Server KMIP Profile
Other post 1.0 profile conformance:  - ASYM_PROFILE 1.1 Basic Asymmetric Key Store - ASYM_PROFILE 1.2 Basic Asymmetric Key and Certificate Store  Not-yet-supported (requires RE_KEY_KEY_PAIR and RE_CERTIFY) conformance:  - ASYM_PROFILE 1.3 Basic Asymmetric Key Foundry and Server  - ASYM_PROFILE 1.4 Basic Certificate Server
Tim Hudson -   http://www.cryptsoft.com/kmip/
← Prev in month ← Prev in thread
Next in thread → Next in month →