1 / 4

NIST Key State Models

NIST Key State Models. SP800-57 Part 1. SP800-130 (Draft). KMIP Key Role Types. Key Role Type 1.1. Proposal for 1.2. KMIP Profiles. Purpose is to define what any implementation of the specification must adhere to in order to claim conformance

ulla
Download Presentation

NIST Key State Models

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NIST Key State Models SP800-57 Part 1 SP800-130 (Draft)

  2. KMIP Key Role Types Key Role Type 1.1 Proposal for 1.2

  3. KMIP Profiles • Purpose is to define what any implementation of the specification must adhere to in order to claim conformance • Define the use of KMIP objects, attributes, operations, message elements and authentication methods within specific contexts of KMIP server and client interaction • Define a set of normative constraints for employing KMIP within a particular environment or context of use • Optionally, require the use of specific KMIP functionality or in other respects define the processing rules to be followed by profile actors (e.g. Server & Client) • Defined OASIS Profiles • Profiles are further qualified by authentication suite • TLS V1.0 / V1.1 / V1.2 or similar • External Profile in development – (Not OASIS developed) • INCITS T10 profile – Fibre Channel Security Protocol v2.0 (FCSP2)

  4. Defining Profiles • Server requirements (required) • Includes all objects, operations and attributes that a client can access • Defined down to all required components of those objects, operations and attributes • Even if optional in KMIP specification, it can be required in a profile • Definition of any extensions and how they are to be used • Client requirements (optional) • What are the bare minimum requirements for a Client to claim conformance • e.g. Must support get of a symmetric key using unique identifier • Can be a single statement • Basically states that support of any operation, object and attributes that are supported by the server and you can be conformant • Protocol requirements (recommended) • Wire protocol KMIP messaging uses (e.g. SSL 3.0, TLS v1.2, FCSP, etc…) • Authentication requirements (recommended) • Certificates, user ID/password, mutual authentication, DH-CHAP, etc… • Interoperability Requirements (recommended) • How to prove conformance either as part of the profile or as a separate Test Case guide • Use Cases (recommended) • How objects, operations and attributes are to be used with message examples

More Related