D.3 KMS responses

33.1803GPPRelease 17Security of the Mission Critical (MC) serviceTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

D.3.1 General

This clause defines the HTTP responses made by the KMS to KMS requests. The KMS attaches XML content to the HTTP responses. The XML serves to provision the client based upon its request.

Though a "KmsResponse" message containing a "KmsMessage" Type is the general response to any request, the content of the "KmsMessage" varies depending on the exact response type (i.e. KmsInit, KmsKeyProv, KmsCertCache, KmsLookup).

The content provided within a KmsInit, KmsKeyProv, KmsCertCache or KmsLookup may include a TrK, InK, KMS URIs, (public) KMS Certificates, (private) user Key Set provisioning, or combinations thereof.

The "KmsResponse" message is shown in Table D.3.1-1.

Table D.3.1-1: Contents of a "KmsResponse" message

Name	Description
UserUri	URI of the user for which the response is intended.
KmsUri	The URI of the KMS sending the response.
KmsId	(Optional) The ID of the KMS providing the response message.
Time	Date/time that the response is sent by the KMS.
ClientReqUrl	The resource client URI from where the request originated.
KmsMessage	One of the following response types: KmsInit, KmsKeyProv, KmsCertCache, or KmsLookup.
TrK-ID	(Optional) The ID of the TrK used to confidentiality protect the KmsMessage.
Signature-ID	(Optional) The ID of the key used to sign the KmsMessage.

In response to a "KMS Initialize" request, the KMS shall respond with the KMS’s own certificate (the Root KMS certificate), and may respond with a new TrK and/or a new InK. The data is returned within a "KMSInit" tag.

In response to a "KMS KeyProvision" request, the KMS shall provision appropriate user Key Sets within a "KMSKeyProv" tag, and may also respond with a new TrK and/or a new InK.

In response to a "KMS CertCache" request, the KMS shall provision a cache of KMS certificates allowing inter-domain communications within a "KMSCertCache" tag.

In response to a "KMS Cert" request, the KMS shall provision a single KMS certificate within a "KMSCertCache" tag. If the requested KMS Certificate is not available, then an error message is returned.

In response to a "KMS Lookup" request, the KMS shall provide information on the KMS URI associated with the requested SIP URI, within a "KMSLookup" tag.

The KMS does not respond to a "KMS Redirect Upload" message, unless an error occurs.

When confidentiality is applied to the KmsResponse payload (KmsMessage), the KMS shall use the TrK currently residing in the MC UE to encrypt the KmsMessage. The associated TrK-ID shall then be included in the KmsResponse message as shown in Table D.3.1-1.

When a signature is applied to the KmsResponse message, the Signature-ID field in Table D.3.1-1 shall be present and indicate either the InK-ID if the InK is used or the TrK-ID if the TrK is used. When a signature is applied and the InK is present, the InK shall be used. When a signature is applied and an InK is not present but a TrK is present, then the TrK shall be used.

The XML schema for the SignedKmsRequestType is provided in Clause D.3.5.1.

D.3.2 KMS certificates

D.3.2.1 Description

A KMS Certificate is a certificate that applies to an entire domain of users. A Certificate consists of XML containing the information required to encrypt messages to a domain of users and verify signatures from the domain of users.

A KMS has exactly one root certificate at any one time, which contains the public keys used by the KMS. The root certificate is the only certificate for which the KMS has the private keys and is able to issue user-specific key material. Should the root certificate need to be updated, a new KMS with a new KMS URI should be established with a new root certificate.

It is assumed that the user is managed by a single KMS. The root certificate for this KMS is required to encrypt messages to the user, and verify signatures from the user.

The KMS may also provision a number of ‘external’ KMS certificates to allow inter-domain communications.

D.3.2.2 Fields

The KMS Certificate shall be within a XML tag named "KmsCertificate". This type shall have the following subfields.

Table D.3.2.2-1: Contents of a KMS Certificate

Name	Description
Version	(Attribute) The version number of the certificate type (‘1. 2.0’ or ‘1.1.0’).
Role	(Attribute) This shall indicate whether the certificate is a "Root" or "External" certificate.
CertUri	(Optional) The URI of the Certificate (this object).
KmsUri	The URI of the KMS which issued the Certificate.
Issuer	(Optional) String describing the issuing entity.
ValidFrom	(Optional) Date from which the Certificate may be used.
ValidTo	(Optional) Date at which the Certificate expires.
Revoked	(Optional) A Boolean value defining whether a Certificate has been revoked.
UserIDFormat	Shall contain the value ‘2’, indicating that the generation mechanism defined in clause F.2.1 shall be used.
UserKeyPeriod	The number of seconds that each user key issued by this KMS should be used (e.g. ‘2419200’).
UserKeyOffset	The offset in seconds from 0h on 1^st Jan 1900 that the segmentation of key periods starts (e.g. ‘0’).
PubEncKey	The SAKKE Public Key, "Z_T", as defined in [10]. This is an OCTET STRING encoding of an elliptic curve point.
PubAuthKey	The ECCSI Public Key, "KPAK" as defined in [9]. This is an OCTET STRING encoding of an elliptic curve point.
ParameterSet	(Optional) The choice of parameter set used for SAKKE and ECCSI (e.g. ‘1’).
KmsDomainList	(Optional) List of domains associated with the certificate.
IsSecurityGateway	(Optional Attribute) Is ‘true’ if the KMS Certificate corresponds to a pseudo-KMS within a MC Security Gateway. If present, the version number of the certificate shall be ‘1.2.0’.

D.3.2.3 User IDs

To secure communications with a specific user, the initiator shall compose the User Identifier (UID) to which the message will be encrypted. IETF RFC 6509 [11] defines a UID generation scheme for Tel URIs, however this cannot be used with Mission Critical Services as MC Service IDs are not Tel URIs.

Clause F.2.1 defines the UID generation scheme for the Mission Critical System. This shall be identified within the KMS certificate by using the value ‘2’ within the UserIDFormat field.

D.3.3 User Key Provision

D.3.3.1 Description

User keys are private information associated to a user’s identity (UserID) which allow a user to decrypt information encrypted to that identity and sign information as that identity. User keys are provisioned as XML containing the key information required and associated metadata.

D.3.3.2 Fields

The KMS shall provision keys within an XML tag named "KmsKeySet". This shall have the following subfields.

Table D.3.3.2-1: Contents of a KMS Key Set

Name	Description
Version	(Attribute) The version number of the key provision XML (1.1.0).
KmsUri	The URI of the KMS which issued the key set.
CertUri	(Optional) The URI of the Certificate which may be used to validate the key set.
Issuer	(Optional) String describing the issuing entity.
UserUri	URI of the user for which the key set is issued.
UserID	Base64 encoded UID corresponding to the key set.
ValidFrom	(Optional) Date and time from which the key set may be used.
ValidTo	(Optional) Date and time at which the key set expires.
KeyPeriodNo	Current Key Period No. since 1 January 1900 (e.g. 1514)
Revoked	(Optional) A Boolean value defining whether the key set has been revoked.
UserDecryptKey	The SAKKE "Receiver Secret Key" as defined in [10]. This is an OCTET STRING encoding of an elliptic curve point as defined in section 2.2 of [30].
UserSigningKeySSK	The ECCSI private Key, "SSK" as defined in [9]. This is an OCTET STRING encoding of an integer as described in section 6 of [31].
UserPubTokenPVT	The ECCSI public validation token, "PVT" as defined in [9]. This is an OCTET STRING encoding of an elliptic curve point as defined in Section 2.2 of [30].

NOTE: The key may be valid outside of its defined key period of use to enable decryption of old messages encrypted to the user.

D.3.4 Example KMS response XML

D.3.4.1 Example KMSInit XML

If the security extension is used, it is assumed that before this response is received, the secure element within the KMS and the secure element within the key management client have shared a bootstrap TrK, e.g. ‘tk.11.user@example.org’.

In this example, the KMS provides the user with the KMS root certificate and a new TrK to protect future KMS communications. Keys are encrypted and the message is signed using the bootstrap TrK.

EXAMPLE:

<?xml version="1.0" encoding="UTF-8"?>

<SignedKmsResponse xmlns="urn:3gpp:ns:mcsecKMSInterface:1.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

Id="xmldoc">

<UserUri>example:user@example.org</UserUri>

<KmsUri>kms.example.org</KmsUri> <Time>2014-01-26T10:05:52</Time>

<KmsId>KMSProvider12345</KmsId>

<ClientReqUrl>http://kms.example.org/keymanagement/identity/v1/init</ClientReqUrl>

<CertUri>cert1.kms.example.org</CertUri>

<KmsUri>kms.example.org</KmsUri>

<Issuer>www.example.org</Issuer>

<Revoked>false</Revoked>

<KmsDomain>sec1.example.org</KmsDomain>

<KmsDomain>sec2.example.org</KmsDomain>

</KmsDomainList>

</KmsCertificate>

<ds:KeyInfo>

<ds:KeyName>

tk.11.user@example.org</ds:KeyName>

</ds:KeyInfo>

<CipherValue>DEADBEEF</CipherValue>

</CipherData>

<CarriedKeyName>tk.12.user@example.org</CarriedKeyName>

</EncryptedKey>

</NewTransportKey>

<ds:KeyInfo>

<ds:KeyName>

tk.11.user@example.org</ds:KeyName>

</ds:KeyInfo>

<CipherValue>DEADBEEF</CipherValue>

</CipherData>

<CarriedKeyName>ink.12.user@example.org</CarriedKeyName>

</EncryptedKey>

</NewIntegrityKey>

</KmsInit>

</KmsMessage>

</KmsResponse>

</SignatureMethod>

</Reference>

</SignedInfo>

<SignatureValue>DEADBEEF</SignatureValue>

<KeyName>tk.11.user@example.org</KeyName>

</KeyInfo>

</Signature>

</SignedKmsResponse>

D.3.4.2 Example KMSKeyProv XML

In this example, the user’s key material is provided for two user identifiers. The key material includes the UserDecryptKey (see IETF RFC 6508 [10]) and the UserSigningKey and PVT (see IETF RFC 6507 [9]) for each identifier.

As the security extension has been used, the key material is encrypted using the shared TrK and the message signed using the shared InK. Additionally, a new TrK is provided as part of the key provision.

EXAMPLE:

<?xml version="1.0" encoding="UTF-8"?>

<SignedKmsResponse xmlns="urn:3gpp:ns:mcsecKMSInterface:1.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

Id="xmldoc">

<UserUri>example:user@example.org</UserUri>

<KmsUri>kms.example.org</KmsUri> <Time>2014-01-26T10:07:14</Time>

<KmsId>KMSProvider12345</KmsId>

<ClientReqUrl>http://kms.example.org/keymanagement/identity/v1/keyprov</ClientReqUrl>

<KmsUri>kms.example.org</KmsUri>

<CertUri>cert1.kms.example.org</CertUri>

<Issuer>www.example.org</Issuer>

<UserUri>example:user@example.org</UserUri>

<UserID>0123456789ABCDEF0123456789ABCDEF</UserID>

<Revoked>false</Revoked>

<ds:KeyInfo>

<ds:KeyName>tk.12.user@example.org</ds:KeyName>

</ds:KeyInfo>

<CipherValue>DEADBEEF</CipherValue>

</CipherData>

</EncryptedKey>

</UserDecryptKey>

<ds:KeyInfo>

<ds:KeyName>tk.12.user@example.org</ds:KeyName>

</ds:KeyInfo>

<CipherValue>DEADBEEF</CipherValue>

</CipherData>

</EncryptedKey>

</UserSigningKeySSK>

<ds:KeyInfo>

<ds:KeyName>tk.12.user@example.org</ds:KeyName>

</ds:KeyInfo>

<CipherValue>DEADBEEF</CipherValue>

</CipherData>

</EncryptedKey>

</UserPubTokenPVT>

</KmsKeySet>

<KmsUri>kms.example.org</KmsUri>

<CertUri>cert1.kms.example.org</CertUri>

<Issuer>www.example.org</Issuer>

<UserUri>example:user.pseudonym@example.org</UserUri>

<UserID>0011223344556677889900AABBCCDDEEFF</UserID>

<Revoked>false</Revoked>

<ds:KeyInfo>

<ds:KeyName>tk.12.user@example.org</ds:KeyName>

</ds:KeyInfo>

<CipherValue>DEADBEEF</CipherValue>

</CipherData>

</EncryptedKey>

</UserDecryptKey>

<ds:KeyInfo>

<ds:KeyName>tk.12.user@example.org</ds:KeyName>

</ds:KeyInfo>

<CipherValue>DEADBEEF</CipherValue>

</CipherData>

</EncryptedKey>

</UserSigningKeySSK>

<ds:KeyInfo>

<ds:KeyName>tk.12.user@example.org</ds:KeyName>

</ds:KeyInfo>

<CipherValue>DEADBEEF</CipherValue>

</CipherData>

</EncryptedKey>

</UserPubTokenPVT>

</KmsKeySet>

<ds:KeyInfo>

<ds:KeyName>tk.12.user@example.org</ds:KeyName>

</ds:KeyInfo>

<CipherValue>DEADBEEF</CipherValue>

</CipherData>

<CarriedKeyName>tk.13.user@example.org</CarriedKeyName>

</EncryptedKey>

</NewTransportKey>

</KmsKeyProv>

</KmsMessage>

</KmsResponse>

</SignatureMethod>

</Reference>

</SignedInfo>

<SignatureValue>DEADBEEF</SignatureValue>

<KeyName>ink.12.user@example.org</KeyName>

</KeyInfo>

</Signature>

</SignedKmsResponse>

D.3.4.3 Example KMSCertCache XML

In this example, a number of ‘external’ KMS certificates are provided to the user. These allow the user to encrypt to users managed by a different KMS.

As the security extension is in use, the message is signed using the shared InK.

EXAMPLE:

<?xml version="1.0" encoding="UTF-8"?>

<SignedKmsResponse xmlns="urn:3gpp:ns:mcsecKMSInterface:1.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

Id="xmldoc">

<UserUri>example:user@example.org</UserUri>

<KmsUri>kms.example.org</KmsUri>

<KmsId>KMSProvider12345</KmsId>

<ClientReqUrl>http://kms.example.org/keymanagement/identity/v1/certcache</ClientReqUrl>

<CertUri>cert2.kms.example.org</CertUri>

<KmsUri>kms.example.org</KmsUri>

<Issuer>www.example.org</Issuer>

<Revoked>false</Revoked>

<KmsDomain>sec3.example.org</KmsDomain>

</KmsDomainList>

</KmsCertificate>

</Reference>

</SignedInfo>

<SignatureValue>DEADBEEF</SignatureValue>

<KeyName>cert1.kms.example.org</KeyName>

</KeyInfo>

</Signature>

</SignedKmsCertificate>

<CertUri>cert1.kms.another.example.org</CertUri>

<KmsUri>kms.another.example.org</KmsUri>

<Issuer>www.another.example.org</Issuer>

<Revoked>false</Revoked>

<KmsDomain>another.example.org</KmsDomain>

</KmsDomainList>

</KmsCertificate>

</Reference>

</SignedInfo>

<SignatureValue>DEADBEEF</SignatureValue>

<KeyName>cert1.kms.example.org</KeyName>

</KeyInfo>

</Signature>

</SignedKmsCertificate>

</KmsCertCache>

</KmsMessage>

</KmsResponse>

</SignatureMethod>

</Reference>

</SignedInfo>

<SignatureValue>DEADBEEF</SignatureValue>

<KeyName>ink.12.user@example.org</KeyName>

</KeyInfo>

</Signature>

</SignedKmsResponse>

D.3.5 KMS response XML schema

D.3.5.1 Base XML schema

This clause contains the XML schema for KMS responses. This will validate Version ‘1.1.0’ or ‘1.2.0’ certificates:

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"

xmlns:krr="urn:3gpp:ns:mcsecKMSKRR:1.0"

xmlns="urn:3gpp:ns:mcsecKMSInterface:1.0"

targetNamespace="urn:3gpp:ns:mcsecKMSInterface:1.0"

elementFormDefault="qualified" version="1.0">

<xsd:import namespace = "http://www.w3.org/2000/09/xmldsig#" />

<xsd:import namespace = "http://www.w3.org/2001/04/xmlenc#" />

<xsd:import namespace ="urn:3gpp:ns:mcsecKMSKRR:1.0"/>

<!– Global elements –>

<xsd:element name="KmsRequest" type="KmsRequestType" />

<xsd:element name="SignedKmsRequest" type="SignedKmsRequestType"/>

<xsd:element type="KmsResponseType" name="KmsResponse"/>

<xsd:element type="SignedKmsResponseType" name="SignedKmsResponse"/>

<!– KMS Request Type definitions (see clause D.2.2) –>

<xsd:complexType name = "KmsRequestType">

<xsd:sequence>

<xsd:element name="UserUri" type="xsd:anyURI"/>

<xsd:element name="KmsUri" type="xsd:anyURI"/>

<xsd:element name="Time" type="xsd:dateTime"/>

<xsd:element name="ClientId" type="xsd:string" minOccurs="0"/>

<xsd:element name="DeviceId" type="xsd:string" minOccurs="0"/>

<xsd:element name="ClientReqUrl" type="xsd:anyURI"/>

<xsd:element name="KrrList" type="krr:KmsRedirectResponseType" minOccurs="0"></xsd:element>

<xsd:element name="ClientError" type="ErrorType" minOccurs="0"/>

<!– Can extend in another namespace – for more types of communication–>

<xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

<xsd:attribute name="Id" type="xsd:string"/>

<xsd:attribute name="Version" type="xsd:string" fixed="1.1.0"/>

<xsd:anyAttribute namespace="##other" processContents="lax"/>

</xsd:complexType>

<xsd:complexType name="SignedKmsRequestType">

<xsd:sequence>

<xsd:element name="KmsRequest" type="KmsRequestType"/>

<xsd:element ref="ds:Signature"/>

</xsd:sequence>

<xsd:attribute name="Id" type="xsd:string"/>

<xsd:anyAttribute namespace="##other" processContents="lax"/>

</xsd:complexType>

<xsd:complexType name = "ErrorType">

<xsd:sequence>

<xsd:element type = "xsd:integer" name = "ErrorCode" maxOccurs = "1"/>

<xsd:element type = "xsd:string" name = "ErrorMsg" maxOccurs = "1"/>

<xsd:any namespace = "##other" processContents = "lax" minOccurs = "0" maxOccurs = "unbounded"/>

</xsd:sequence>

<xsd:attribute name = "Id" type = "xsd:string"/>

<xsd:attribute name = "Version" type = "xsd:string"/>

<xsd:anyAttribute namespace = "##other" processContents = "lax"/>

</xsd:complexType>

<!– KMS Response Type definitions (see clause D.2.3) –>

<xsd:complexType name="KmsResponseType">

<xsd:sequence>

<xsd:element name="UserUri" type="xsd:anyURI"/>

<xsd:element name="KmsUri" type="xsd:anyURI"/>

<xsd:element name="Time" type="xsd:dateTime"/>

<xsd:element name="KmsId" type="xsd:string" minOccurs = "0"/>

<xsd:element name="ClientReqUrl" type = "xsd:anyURI"/>

<xsd:element name="KmsMessage" type="KMSMessage" minOccurs = "0" />

<xsd:element name="KmsError" type="ErrorType" minOccurs = "0"/>

<xsd:any namespace = "##other" processContents = "lax" minOccurs = "0" maxOccurs = "unbounded"/>

</xsd:sequence>

<xsd:attribute name="Id" type="xsd:string"/>

<xsd:attribute name="Version" type="xsd:string" fixed="1.0.0"/>

<xsd:anyAttribute namespace="##other" processContents="lax"/>

</xsd:complexType>

<xsd:complexType name="SignedKmsResponseType">

<xsd:sequence>

<xsd:element ref="KmsResponse"/>

<xsd:element ref="ds:Signature" minOccurs="0"/>

</xsd:sequence>

<xsd:attribute name="Id" type="xsd:string"/>

<xsd:anyAttribute namespace="##other" processContents="lax"/>

</xsd:complexType>

<xsd:complexType name="KMSMessage">

<xsd:choice>

<xsd:element name="KmsInit" type="KmsInitType"/>

<xsd:element name="KmsKeyProv" type="KmsKeyProvType"/>

<xsd:element name="KmsCertCache" type="KmsCertCacheType"/>

<xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xsd:choice>

<xsd:anyAttribute namespace="##other" processContents="lax"/>

</xsd:complexType>

<xsd:complexType name="KmsInitType">

<xsd:sequence>

<xsd:choice>

<xsd:element name="SignedKmsCertificate" type="SignedKmsCertificateType"/>

<xsd:element name="KmsCertificate" type="KmsCertificateType"/>

</xsd:choice>

<xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

<xsd:attribute name="Id" type="xsd:string"/>

<xsd:attribute name="Version" type="xsd:string"/>

<xsd:anyAttribute namespace="##other" processContents="lax"/>

</xsd:complexType>

<xsd:complexType name="KmsKeyProvType">

<xsd:sequence>

<xsd:element name="KmsKeySet" type="KmsKeySetType" minOccurs="0" maxOccurs="unbounded"/>

<xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

<xsd:attribute name="Id" type="xsd:string"/>

<xsd:attribute name="Version" type="xsd:string" fixed="1.0.0"/>

<xsd:anyAttribute namespace="##other" processContents="lax"/>

</xsd:complexType>

<xsd:complexType name="KmsCertCacheType">

<xsd:sequence>

<xsd:element name="SignedKmsCertificate" type="SignedKmsCertificateType" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element name="KmsCertificate" type="KmsCertificateType" minOccurs="0" maxOccurs="unbounded"/>

<xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

<xsd:attribute name="Id" type="xsd:string"/>

<xsd:attribute name="Version" type="xsd:string" fixed="1.0.0"/>

<xsd:attribute name="CacheNum" type="xsd:integer"/>

<xsd:anyAttribute namespace="##other" processContents="lax"/>

</xsd:complexType>

<!– KmsCertificate definition – see clause D.3.2.2 –>

<xsd:element name = "KmsCertificate" type = "KmsCertificateType"/>

<xsd:complexType name = "KmsCertificateType">

<xsd:sequence>

<xsd:element name="CertUri" type="xsd:anyURI" minOccurs = "0"/>

<xsd:element name="KmsUri" type="xsd:anyURI"/>

<xsd:element name="Issuer" type="xsd:string" minOccurs = "0"/>

<xsd:element name="ValidFrom" type="xsd:dateTime" minOccurs = "0"/>

<xsd:element name="ValidTo" type="xsd:dateTime" minOccurs = "0"/>

<xsd:element name="Revoked" type="xsd:boolean" minOccurs = "0"/>

<xsd:element name="UserIdFormat" type="xsd:string"/>

<xsd:element name="UserKeyPeriod" type="xsd:integer"/>

<xsd:element name="UserKeyOffset" type="xsd:integer"/>

<xsd:element name="PubEncKey" type="xsd:hexBinary"/>

<xsd:element name="PubAuthKey" type="xsd:hexBinary"/>

<xsd:element name="ParameterSet" type="xsd:integer" minOccurs = "0"/>

<xsd:element name="KmsDomainList" minOccurs = "0">

<xsd:complexType>

<xsd:sequence>

<xsd:element type = "xsd:anyURI" name = "KmsDomain" maxOccurs = "unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:any namespace = "##other" processContents = "lax" minOccurs = "0" maxOccurs = "unbounded"/>

</xsd:sequence>

<xsd:attribute name = "Id" type = "xsd:string"/>

<xsd:attribute name = "Version" type = "xsd:string"/>

<xsd:attribute name = "Role" type = "RoleType"/>

<xsd:attribute name = "IsSecurityGateway" type = "xsd:boolean" use="optional"/>

<xsd:anyAttribute namespace = "##other" processContents = "lax"/>

</xsd:complexType>

<xsd:simpleType name = "RoleType">

<xsd:restriction base = "xsd:string">

<xsd:enumeration value = "Root"/>

<xsd:enumeration value = "External"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:element name="SignedKmsCertificate" type="SignedKmsCertificateType"/>

<xsd:complexType name="SignedKmsCertificateType">

<xsd:sequence>

<xsd:element name="KmsCertificate" type="KmsCertificateType"/>

<xsd:element ref="ds:Signature" minOccurs="0"/>

</xsd:sequence>

<xsd:attribute name="Id" type="xsd:string"/>

<xsd:anyAttribute namespace="##other" processContents="lax"/>

</xsd:complexType>

<xsd:element name="KmsKeySet" type="KmsKeySetType"/>

<xsd:complexType name = "KmsKeySetType">

<xsd:sequence>

<xsd:element name="KmsUri" type="xsd:anyURI"/>

<xsd:element name="CertUri" type="xsd:anyURI" minOccurs = "0"/>

<xsd:element name="Issuer" type="xsd:string" minOccurs = "0"/>

<xsd:element name="UserUri" type="xsd:anyURI"/>

<xsd:element name="UserID" type="xsd:string"/>

<xsd:element name="ValidFrom" type="xsd:dateTime" minOccurs = "0"/>

<xsd:element name="ValidTo" type="xsd:dateTime" minOccurs = "0"/>

<xsd:element name="KeyPeriodNo" type="xsd:integer"/>

<xsd:element name="Revoked" type="xsd:boolean" minOccurs = "0"/>

<xsd:element name="UserDecryptKey" type="abstractKeyContentType"/>

<xsd:element name="UserSigningKeySSK" type="abstractKeyContentType"/>

<xsd:element name="UserPubTokenPVT" type="abstractKeyContentType"/>

</xsd:sequence>

<xsd:attribute name="Id" type="xsd:string"/>

<xsd:attribute name="Version" type="xsd:string" fixed="1.1.0"/>

<xsd:anyAttribute namespace="##other" processContents="lax"/>

</xsd:complexType>

<xsd:complexType name="abstractKeyContentType" abstract="true" mixed="true" />

<xsd:complexType name = "KeyContentType">

<xsd:simpleContent>

<xsd:restriction base = "abstractKeyContentType">

<xsd:simpleType>

<xsd:restriction base="xsd:hexBinary"></xsd:restriction>

</xsd:simpleType>

</xsd:restriction>

</xsd:simpleContent>

</xsd:complexType>

<xsd:complexType name="EncKeyContentTypeMixed" mixed="false" abstract="true">

<xsd:complexContent>

<xsd:restriction base="abstractKeyContentType">

<xsd:sequence>

</xsd:sequence>

</xsd:restriction>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name="EncKeyContentType">

<xsd:complexContent>

<xsd:extension base="EncKeyContentTypeMixed">

<xsd:sequence>

<xsd:element ref="xenc:EncryptedKey"/>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name="KmsInitTkIkType">

<xsd:complexContent>

<xsd:extension base="KmsInitType">

<xsd:sequence>

<xsd:element type="EncKeyContentType" name="NewTransportKey" maxOccurs="unbounded" minOccurs="0"/>

<xsd:element type="EncKeyContentType" name="NewIntegrityKey" maxOccurs="unbounded" minOccurs="0"/>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name = "KmsKeyProvTkIkType">

<xsd:complexContent>

<xsd:extension base="KmsKeyProvType">

<xsd:sequence>

<xsd:element type="EncKeyContentType" name="NewTransportKey" maxOccurs="unbounded" minOccurs="0"/>

<xsd:element type="EncKeyContentType" name="NewIntegrityKey" maxOccurs="unbounded" minOccurs="0"/>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

</xsd:schema>

D.3.1 General

D.3.2 KMS certificates

D.3.2.1 Description

D.3.2.2 Fields

D.3.2.3 User IDs

D.3.3 User Key Provision

D.3.3.1 Description

D.3.3.2 Fields

D.3.4 Example KMS response XML

D.3.4.1 Example KMSInit XML

D.3.4.2 Example KMSKeyProv XML

D.3.4.3 Example KMSCertCache XML

D.3.5 KMS response XML schema

D.3.5.1 Base XML schema

D.3.5.2 Void