The JSON representations for KMS key objects is defined as follows using JSON content rules
jwk : ; see [JWK]
kmsUri (
"uri" : uri relative
)
keyRep {
kmsUri,
"jwk" : jwk,
"userId" : string,
"clientId" : string,
"createDate" : date-time,
"expirationDate" : date-time,
?"resourceUri" : kmsUri,
?"bindDate" : date-time
}
key (
"key" : keyRep
)
keys (
"keys" : [ *keyRep ]
)
keyUris (
"keyUris" : [ *kmsUri ]
)
The attributes of a KMS key object are defined as follows.
uri
A standard definition for KMS object identifiers.
jwk
Symmetric keying material represented as a JWK object (see
[I-D.ietf-jose-json-web-key]).
userId
The authenticated unique identifier of the user that created the
key.
clientId
Biggs & Cooley Expires January 4, 2016 [Page 18]
Internet-Draft key-management-service July 2015
An opaque unique identifier provided by the client that created
the key.
createDate
The point in time when the key was created, in [RFC3339] date-time
format.
expirationDate
The point in time after which the key may no longer be bound (if
unbound) or may no longer be used for encrypting data (if bound or
an ephemeral key).
resourceUri
The uri of the KMS resource object to which the key is bound.
bindDate
The point in time when the key was bound, in [RFC3339] date-time
format.
KMS Authorization Objects
The JSON representations for KMS authorization objects is defined as
follows using JSON content rules with references to rules defined in
previous sections.
authorizationRep {
kmsUri,
"authId" : string,
"createDate" : date-time,
"resourceUri" : kmsUri,
}
authorization (
"authorization" : authorizationRep
)
authorizations (
"authorizations" : [ *authorizationRep ]
)
authorizationUris (
"authorizationUris" : [ *kmsUri ]
)
The attributes of a KMS authorization object are defined as follows.
uri
A standard definition for KMS object identifiers.
authId
A unique identifier of the authorized entity. The exact semantics
of this attribute are out of scope for this document, however it
is RECOMMENDED that an implementation regard the value of this
attribute as mapped to either an individual identity or a grouping
of identities as recognized by the identity provider employed by
the KMS.
createDate
The point in time when the authorization was created, in [RFC3339]
date-time format.
resourceUri
The object identifier of the resource to which the authorization
applies.
Note, with respect to this specification user identifiers are opaque,
however they MUST map to unique identifiers provided as part of user
authentication.
KMS Resource Objects (KRO)
The JSON representation for KMS resource objects is defined as
follows using JSON content rules with references to rules defined in
previous sections.
resourceRep {
kmsUri,
keys / keyUris,
authorizations / authorizationUris
}
resource (
"resource" : resourceRep
)
resources (
"resources" : [ *resourceRep ]
)
resourceUris (
"resourceUris" : [ *kmsUri ]
)
The attributes of a KMS resource object are defined as follows.
uri
A standard definition for KMS object identifiers.
keys
An array of key object representations, one for each key bound to
the resource.
keyUris
An array of key object identifiers, one for each key bound to the
resource. Only one of either keys or keyUris may be present in a
resource object representation.
authorizations
An array of authorization object representations, one for each
authorization on the resource.
authorizationUris
An array of authorization object identifiers, one for each
authorization on the resource. Only one of either authorizations
or authorizationUris may be present in a resource object
representation.
Request Types
The KMS protocol defines four types of requests: create, retrieve,
update, delete, each of which may be applied to one of the three KMS
object types. Note that not all object types support all requests
types. A KMS need only support those combinations of request type
and object type explicitly defined in this document.
Create
A create operation acts upon an object type, creating one or more
new instances of that object type.
Retrieve
A retrieve operation acts upon an object or object type, returning
in the response a representation of one or more object instances.
Update
An update operation acts upon an object, altering mutable
properties of that object.
Delete
A delete operation acts upon an object, removing that object from
the KMS.
Message Structure
Every KMS request and response message is composed of a JSON
[RFC7159] formatted payload encapsulated within either a JWE
[I-D.ietf-jose-json-web-encryption] or JWS
[I-D.ietf-jose-json-web-signature] object. These messages may be
divided into three types.
Common Messages
Common messages include all those which do not meet the definition
of either key agreement message or error message. Common messages
are encrypted as JWE objects using the shared ephemeral key
established during initial key agreement between the client and
KMS (see Section 4.7.1). The value of the JWE header "kid"
attribute of a common message MUST match that of the KMS ephemeral
key object URI attribute established during initial key agreement.
Ephemeral key agreement messages are those exchanged between the
client and KMS for the purpose of establishing a new shared
ephemeral key (see Section 4.7.1). Key agreement request payloads
are encrypted as JWE objects using the authenticated and validated
static public key of the KMS. Key agreement response payloads are
signed as JWS objects using the static private key of the KMS.
The value of the JWE or JWS header "kid" attribute of an ephemeral
key agreement message MUST be a well known key identifier for the
KMS static public key.
Error Messages
Error messages are those originated by the KMS to indicate a
failed request. Error messages are composed in the same fashion
as common messages; however, in the event that the KMS does not
recognize the ephemeral key used in the request, or that key is
determined to have expired, the KMS MUST respond with an
unencrypted message composed as a JWS, with a payload as described
in Section 4.6.3, and signed using the KMS server's static public
key.
The basic JSON representations for the request and response payloads
are defined in the following sections.
references:
https://datatracker.ietf.org/doc/html/draft-abiggs-saag-key-management-service-02#section-1.1
No comments:
Post a Comment