XML Key Management Service WG Requirements Last Call Comments

Shivaram Mysore < shivaram.mysore@sun.com >
Stephen Farrell < stephen.farrell@baltimore.ie >
Frederick Hirsch < fjh@alum.mit.edu >
Mike Just < mike.just@entrust.com >

This page links to comments/issues raised on the list during Last Call (March 18 - April 15, 2002) and their resolution for the Requirements Document . A style sheet declaration is used to not render issues that are considered 'done'. The source of an issue need not be its first instance, it also might reference a cogent description or WG poll. Also, this document may not capture editorial tweaks and errors that were easily and quickly remedied.

Resolutions are expressed as {email,minutes} » (resulting) draft

Issues Raised During Requirements Last Call

For Discussion

Source Issue [Proposed] Resolution
Denis Pinkas
Make policy definition explicit and separate from server URL locator. Convey in request and response payloads explicitly. (e.g. URI for OID?)

Deferred Request Authentication definition
Capabilites #9: policy as example of context
Enables cooperating trust servers to share information and delegate services without relying on location for policy.
 Make policy URI explicit in requests and responses and do not rely on HTTP URI for policy implications.

Blair Dillaway
Require SOAP 1.2 instead of 1.1

Denis Pinkas
Do not require client to cache request to validate returned hash. Extend definition of request/response to add that server MAY(?) return a copy of relevant parameters in the request so that a client may use these to unambiguously identify the request".
Transaction Security #5
Might raise issues of what is unambigous and how server should know what to return.
Denis Pinkas
Remove requirement to support key usage - can be embedded in signature as property rather than requiring key binding.
Objects/Processing #2
Although signature may have uses associated with it, server may wish to enforce key usage based on key registration. KeyBinding supports KeyUsage and UseKeyWith elements.
Denis Pinkas
Add OCSP to the list of supported KeyInfo formats when PX509 support is claimed. Reason is interoperability with RFC2459bis
Objects/Processing #4
Add OCSP to list
Denis Pinkas
Change MUST to SHOULD for proof of possession of private keys since not required for encryption keys
Objects/Processing #10
Keep MUST, to avoid impersonation and other potential problems when PoP not used.
Frederick J. Hirsch

Maintain bulk operation as a MUST requirement even though charter indicates definition of bulk is optional?
Should be ok since a separate spec is being produced. Even though the charter doesn't require that we complete this, it seems simple enough to progress along with XKMS.
Joseph Reagle
When using QNames as identifiers do we mean the string consisting of prefix:name or do we mean the {uri, name} tuple?

How to maintain uniformity across ws-security specs?

Are there security issues based on the use of QNames?

Yassir Elley
Does requirement for SOAP binding imply server requirement to implement SOAP interface for XKMS requests and responses?  2.4.10

Server implementation might support HTTP POST of XKMS requests without using SOAP for example.
Intent was that all XKMS servers support SOAP interface.
Al Arsenault
Why treat TLS specially?

(2.1.5, 2.2.1)It seems somewhat inconsistent to say that the design MUST be transport agnostic (2.1.5) and also say that every trust service MUST support TLS (2.2.1). Also, I'm not sure why you're treating TLS differently from IPSEC (2.2.1). There seems to be a mentality that "TLS is a Web service, and IPSEC is something else." From a technical security standpoint, I don't think I necessarily accept that. If I'm missing something, I apologize, but that just seems inconsistent to me.
(Since TLS is a commonly deployed solution it deserves clear mention in the expectation of its use?)
Al Arsenault
Ties to XMLP (2.4.10):
This seems to be saying that "there must be a version 2 of the XKMS Solution. It will be defined to include bindings to the XML protocol once that protocol is defined." I'd suggest saying that more clearly.

(Potentially) Resolved

Source Issue [Proposed] Resolution
Denis Pinkas
Give examples of other means of establishing trust relationships with server.
Trust Service Trust #8:
1. cached server key at client
2. key establishment using shared secret

Denis Pinkas Refine wording of revocation. Specify need to publish revocation.

"The specification MUST describe how revocation of a registered key binding can be requested". Then it be explained how/if the revocation is advertised. Is it through the use of "key binding status check" request and/or a "key binding validation" request ?
Capabilities #2
Revocation does not need to be advertised since clients find it easy and fast to access online server for current status of binding. No local revocation processing required. Key Binding Validation is used.
Denis Pinkas
What is need for update operation when same functionality is possible with revoke and register.
Capabilities #3
Objects/Processing #1
Reasons include:
1. atomic transaction, no revoked window
2. update some information while retaining other
3. Clarity of messages, no special cases

Denis Pinkas
Eliminate requirement for opaque data support, to enable interoperability.
Retain requirement - opaque data may be ignored by applications that don't care.
Denis Pinkas
Non-repudiation must be removed from out of scope list if signing purpose requirement remains
Out of Scope #2 (Objects/Processing #2)
Defining key usage binding does not imply full requirement for non-repudiation specification.
Jon Gunderson
I noticed that your charter said that DOM implementation issues was out of scope for your document. I have concerns here, since one of the issues in the User Agent working group is dealing with is access to secure documents for alternative rendering. Ideally, this would be a lot easier if there was an interoperable way for security information to be transmitted through the DOM. UAAG has a requirement to export the DOM to assistive technologies for them to provide alternative renderings of alternative controls. I think that a standard DOM implementation for people to gain access to content in a secure way is important for accessibility. I'm not sure how this translates into your requirements document.
Not clear that a requirement needs to be added. The requirements do not specify server implementation technology.
Yassir Elley (Blair Dillaway, Stephen Farrell, Ed Simon)
Constrained device support.
Devices must able to compose and parse the XML associated with the XKMS messages required by their application(s). But, it isn't required they support a general purpose XML parsing capability.
Add to 2.1:
The specification MUST NOT require that devices need to support a general purpose XML parsing capability.
Al Arsenault
Precluding other authentication mechanisms in 2.5.9.
Suggest that the last sentence of 2.5.9 be removed.
Frederick J. Hirsch
Change requirement for introspection from MUST to MAY


Change 2.3.1. as follows:
s/Provide server introspection/Trust servers MAY provide introspection
Al Arsenault
Key recovery (2.4.4):
Concern that this will be a mandatory feature.
Only mandatory for the spec to describe, not for implementations to support. Requirements spec is fine as-is.
Al Arsenault
Necessity of 2.4.5:
This is really a requirement on the protocol, not on the specification. I don't object to it, but it doesn't seem to really belong here - somebody's just laying a foundation for his/her feature of choice.
No harm with requirement. Fine as-is.
Denis Pinkas
Defer XML extensions to future, enable interoperability
Formats #11
By using XML namespaces and XML extensibility we can retain extensibility now without damaging interoperability. Keep the requirement for extensibility.
Shivaram H. Mysore
Qualify/Define "excessive overhead" when passing requests from one server to another

"Additional latency should only rise linearly with the number of servers chained." (?)


Source Issue [Proposed] Resolution
Yassir Elley
Change requirements on XKMS specification itself to be MUST or MUST NOT rather than SHOULD or SHOULD NOT.

For example, 2.1.8 states
"The specification SHOULD clearly define the set of responses ..."
It seems strange to include this as a requirement and then say that it
it is only a SHOULD. (In other words, it is not really a requirement)
All requirements on specification itself change to MUST or MUST NOT.
Denis Pinkas
Add a definition for "Key Location Service"
Key Location - A service that locates and returns a public key given  identifying information for the key.  Generally the request will include a  KeyInfo  element containing information sufficient for the service to locate the key. A common example is to provide the key name. 
Denis Pinkas
Make explicit that encapsulated PKIX structures such as Certificates, CRLs etc are allowed in XML definitions
Universality+Usability item 2
"Common PKIX structures such as X.509 certificate and CRL structures may be embedded as binary (base64 encoded) data within XML elements."
Frederick J. Hirsch Add language that applications which deal with X.509 certificates will require ASN.1 processing capability.
Add to previous wording, "Applications which expect to process X.509 certificates will require ASN.1 and certificate processing capabilities."
Add third sentence to Section 1:
This simple client is not concerned with the details of the infrastructure required to support the public key management but may choose to work with X.509 certificates. If so the client would need to understand ASN.1 and details of certificate processing.
Denis Pinkas
 Separate validation/status check items from registration and revocation
Capabilities #8, #9
Establish separate sections in Protocol Capabilities and Formats section for KRS and KISS.
Denis Pinkas
Can only validate binding, not public key
Capability #8
Clarify wording that validate binding of key to name or other information mentioned in validate request.
Denis Pinkas
Clarify that although "Expression of existing PKI data structures in XML" is out of scope, use of PKI structures encapsulated in XML required.
Out of Scope #5
Update wording of out of scope #5:
"5. Redefinition of existing PKI structures using an XML syntax. Existing PKI structures may be encapsulated within XML elements, but PKIX structures will not be redefined in XML."

Frederick J. Hirsch Revise wording to not imply that "no security" is third server security option, but rather that an "external" security mechanism is employed. 2.2.1
"...TLS, payload security, and secure networks such as VPNs."
Shivaram H. Mysore
Revise definition of Proof of Possession
"Performing an action with a private key to demonstrate
possession of it. An example is to create a signature using a
registered private signing key, to prove possession of it."
Shivaram H. Mysore
Status of Document formatting:

(Activity Statement) -> [Activity Statement]
pubicly -> publicly
removed in editors draft, 18 Feb 2002
Shivaram H. Mysore
Add reference to Activity Statement in References
Make proposed change
Shivaram H. Mysore
Revise goal statement in introduction
"In particular, it is a goal of XML key management to support the public key management requirements of XML Encryption [XML Encryption], XML Digital Signature [XMLDSIG] and  be consistent with the Security Assertion Markup Language [SAML].
anonymous through Stephen Farrell
Explain relationship to traditional PKI in Introduction and provide more guidance on when XKMS is applicable, in particular when compared to PKI protocols developed by PKIX (e.g. OCSP).
The motivation of changing focus from certificates to keys and offloading complexity of status checking from the client might be an appropriate introductory statement.
Shivaram H. Mysore
Reword Asynchronous Exchange example.
"When client registration requires time consuming checks it is more  practical for a client to return at a later time for a completed response, for example."
Yassir Elley
Replace "PX509" with "X509"
"...if the service claims interoperability with PKIX X.509."

Yassir Elley
"Usability and simplicity are paramount to enable clients to obtain ..."

Yassir Elley
fix fragment
"In particular, the specification MUST define how  transport layer security such as SSL/TLS is to be used."
Frederick Hirsch
Various editorial:
(2.1.7) s/enable client, to obtain/enable/ clients to obtain/
(2.1.8) s/request, will not/request will not/
(2.1.12) s/SHOULD not/SHOULD NOT/
(2.4.15) s/ill effect),/ ill effect/
(2.5.4) s/PX509/X.509/
(2.5.4) s/format which MUST/format MUST/
Make proposed changes.
Liam Quin
Is it for management of XML keys, or for the management of keys using XML? If the former, what is an XML key?
No change. It is for the management of public keys using a protocol defined with XML.
Liam Quin
It might be nice if this document defined the terms "key" and "key management" in its glossary at the start.
Added two new definitions to Section 1:
Key: An input parameter that varies the transformation performed by a cryptographic algorithm [RFC2828]. For the purpose of XML key management, we specifically mean public keys and private keys as used in a public key cryptosystem.
Key Management: Key management relates to the management of a public key's validity status over its lifetime. Typically, operations are defined for controlling the validity (e.g. register, revoke) and querying the validity.
Shivaram H. Mysore 
Various editorial:
(Introduction) Remove redundant "and"s from first paragraph.
(Introduction - Key name) Remove redundant uses of "key" from last sentence.
(Introduction - Payload security) Replace "an" with "a".
(2.2.2) s/be encrypting using/use
(2.2.2) s/XML encryption/XML Encryption
Make proposed changes.
Yassir Elley
Minor changes:
(2.1.7) s/client/clients
(2.2.3) Remove "how"
Make proposed changes.
Al Arsenault
(Introduction - 4-Corner model) s/where end-entities interact/where each end-entity interacts
(2.2.9) s/key(s)/key's
(2.3.1) s/services trust server/services the trust server
(2.5.4) Remove "which" from last sentence.

Issues Raised After 1st Last Call

Source Issue Resolution

Issues Raised in Candidate REC

Source Issue Resolution

Last $Revision$ by $Author$ on $Date$ GMT