xkms
XKMS is the W3C XML Key Management Specification. In order to advance the specification from Candidate Recommendation into Proposed Recommendation and further into ratified specification the XKMS working group needed to demonstrate interoperability between at least two independently developed implementations. To this end, the working group called for implementors to participate in an interoperability activity that culminated in an interop festival.
I am one of the implementors that participated in this activity.
There are essentially two parts to the XKMS specification - a Key Information Service (XKISS) and a Key Registration Service (XKRSS). The former provides key centric discovery and validation services for its clients whereas the latter provides services related to key life cycle management including key generation, registration, reissuance, revocation and recovery. My implementation supports all client and server features of the XKMS specification.
The design of my implementation incorporates support for cryptographic hardware, enabling use of smartcards and HSM's that provide a PKCS#11 interface. This functionality is available for both the client and server side.
As part of my participation in the W3C XKMS interop activity, I am running an XKMS service on the following URL's:
http://markupsecurity.com:4080/xkms/service/{soap12,soap11,plain-http} https://markupsecurity.com:4443/xkms/service/{soap12,soap11,plain-http}
The secure (https) endpoints require ciphersuite TLS_RSA_WITH_3DES-EDE_CBC_SHA and do not require client authentication.
Both unsigned and signed messages are accepted. Failure to verify and validate a signature yields a result indicating Sender.NoAuthentication. All results are signed.
In addition to Synchronous processing, the service also accepts protocol options indicated by the following recommended URI's:
| Protocol Option | URI |
|---|---|
| Asynchronous Processing | http://www.w3.org/2002/03/xkms#Asynchronous |
| Two Phase Request Protocol | http://www.w3.org/2002/03/xkms#Represent |
| Compound Requests and Responses | http://www.w3.org/2002/03/xkms#Compound |
When both two-phase and asynchronous exchanges are indicated, the two-phase exchange takes precedence.
Both SMTP and HTTP notification of asynchronous exchanges are supported.
As a full implementation, the service responds to LocateRequest, ValidateRequest, RegisterRequest, ReissueRequest, RecoverRequest, RevokeRequest, CompoundRequest, StatusRequest and PendingRequest.
Requests for responses with OpaqueClientData and RequestSignatureValue are honored by copying these quantities from the request into the result.
The service reacts to the following RespondWith values:
| RespondWith |
|---|
| http://www.w3.org/2002/03/xkms#KeyValue |
| http://www.w3.org/2002/03/xkms#KeyName |
| http://www.w3.org/2002/03/xkms#X509Cert |
| http://www.w3.org/2002/03/xkms#X509Chain |
| http://www.w3.org/2002/03/xkms#X509CRL * |
| http://www.w3.org/2002/03/xkms#PGP |
* CRL's are generated on the fly.
Following are some additional details about the XKISS and XKRSS parts of my interop service endpoint.
xkiss
The service is pre-loaded with keys and X509 and PGP artifacts submitted as part of sample messages I have produced (and will produce) for the working group; these keys and artifacts can be used as the basis for the XKISS queries and signatures.
The following Application/Identifier combinations are meaningful for use with UseKeyWith:
| Application | Identifier |
|---|---|
| urn:ietf:rfc:2633 | alice@example.com |
| urn:ietf:rfc:2440 | alice@example.com |
| urn:ietf:rfc:2633 | bob@example.com |
| urn:ietf:rfc:2440 | bob@example.com |
| urn:ietf:rfc:2633 | eric@example.com |
| urn:ietf:rfc:2440 | eric@example.com |
| urn:ietf:rfc:2633 | ralph@example.com |
| urn:ietf:rfc:2440 | ralph@example.com |
| urn:ietf:rfc:2633 | mandy@example.com * |
| urn:ietf:rfc:2440 | mandy@example.com * |
| urn:ietf:rfc:2459 | CN=RSA Test CA - No Liability,ST=Dublin,C=IE |
| urn:ietf:rfc:2818 | markupsecurity.com |
| http://www.w3.org/2002/03/xkms# | http://markupsecurity.com:4080/xkms/service/soap12 |
| http://www.w3.org/2002/03/xkms# | http://markupsecurity.com:4080/xkms/service/soap11 |
| http://www.w3.org/2002/03/xkms# | http://markupsecurity.com:4080/xkms/service/plain-http |
| http://www.w3.org/2002/03/xkms# | https://markupsecurity.com:4443/xkms/service/soap12 |
| http://www.w3.org/2002/03/xkms# | https://markupsecurity.com:4443/xkms/service/soap11 |
| http://www.w3.org/2002/03/xkms# | https://markupsecurity.com:4443/xkms/service/plain-http |
* Mandy has 10 keypairs bound to the same Application/Identifier pairs.
xkrss
As an interop convention, all HMAC authentication signatures are created using key material derived from the string "secret" (without quotes) using the Limited Use Shared Secret algorithm in Section 8.1 of the XKMS specification. The associated KeyName is XKMSInteropClient. All PrivateKey data is encrypted using the tripleDES algorithm (http://www.w3.org/2001/04/xmlenc#tripledes-cbc).
There is also an enrollment page intended to support the creation of shared secrets and selection of symmetric encryption algorithm. I also provide a more secure variant.
The NotBoundAuthentication feature is supported through an imaginary username/password protocol that carries a username in the Protocol attribute and a base 64 encoded password in the Value attribute, as in the following example.
<NotBoundAuthentication
Protocol="http://www.example.com/foo/protocol?user=xkmsinteropclient"
Value="c2VjcmV0" />
A RegisterRequest and ReissueRequest will produce X509 certificate's and PGP keys when indicated through UseKeyWith.