XML Key Management Service WG Requirements Last Call Comments

Chair(s):: Shivaram Mysore < [email protected] >; Stephen Farrell < [email protected] >
Editors(s):: Frederick Hirsch < [email protected] >; Mike Just < [email protected] >

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	Resolution
1	Denis Pinkas	Make policy definition explicit and separate from server URL locator. Convey in request and response payloads explicitly. (e.g. URI for OID?) Implications: 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.	No change to requirements. Defer to WSDL and UDDI to communicate binding between url and policy. {Resolution, Minutes Issue 1}
2	Blair Dillaway	Require SOAP 1.2 instead of 1.1	The following requirements were revised as follows: 2.1.4) The specification MUST provide a binding to XML Protocol (SOAP 1.2), provided that the SOAP 1.2 specification has reached Candidate Recommendation (CR) status prior to the XKMS WG completing its work. In this case the specification SHOULD also provide a binding to SOAP 1.1 (for interoperability purposes). If SOAP 1.2 has not reached CR status then the specification MUST provide a binding to SOAP 1.1. The XKMS specification SOAP binding is required to profile SOAP for interoperability, including use of document literal encoding. [ SOAP ] [XMLProtocol] [List( Blair Dillaway)]. 2.1.5) XKMS services MUST implement SOAP 1.2 once that specification has achieved Candidate Recommendation status. {Minutes Issue 2 and List}
3	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	No change to requirements. { Resolution , Minutes Issue 3}
4	Denis Pinkas	Remove requirement to support key usage - can be embedded in signature as property rather than requiring key binding. Objects/Processing #2	Revised to clarify requirement at F2F. { Resolution , Minutes Issue 4}
5	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 listof optional X.509 formats - as discussed at F2F, only X509cert is required. Wording revised as follows: 2.5.4 The following KeyInfo formats MUST be supported: KeyName, KeyValue, RetrievalMethod and MgmtData. The X509Certificate KeyInfo format MUST be supported by a trust server if the service claims interoperability with PKIX X.509. Additional KeyInfo formats such as X509Chain, OCSP, and X509CRL MAY be supported. X509Chain and OCSP MUST be defined in the XKMS specifications. X509CRL is defined in the XML Signature recommendation. The XKMS registration Private format MUST be supported if the service supports either service generated key pairs or key recovery.[List( Sebastien Pouliot)] { Resolution , Minutes Issue 5}
6	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. { Resolution , Minutes Issue 6}
7	Frederick J. Hirsch	Maintain bulk operation as a MUST requirement even though charter indicates definition of bulk is optional? 2.4.5	Retain since it seems simple enough to progress along with XKMS. {Resolution, Minutes Issue 7}
8	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?	Defer architecture question - no impact on requirements. {Resolution, Minutes Issue 8}
9	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.	Yes, all XKMS servers must implement a SOAP interface. { See Issue 2}
10	Al Arsenault (04/05/2002)	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.	2.1.5 is meant to ensure agnostic design while 2.2.1 is necessary to ensure interoperability. We revised Requirement 2.2.1 to clarify that servers are required to support TLS and payload security and may opt to support IPSec. We think this captures the intent of the original requirement without the wording of "no security" in the previous version. Although it does treat TLS and payload security a little differently, for interoperability there must be a small set of security services that every service will offer. {Minutes Issue 9}
11	Al Arsenault (04/05/2002)	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	Resolution
12	Denis Pinkas	Give examples of other means of establishing trust relationships with server. Trust Service Trust #8:	Added examples to requirements 1. cached server key at client 2. key establishment using shared secret { Resolution }
13	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. { Resolution }
14	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 { Resolution }
15	Denis Pinkas	Eliminate requirement for opaque data support, to enable interoperability.	Retain requirement - opaque data may be ignored by applications that don't care. { Resolution }
16	Denis Pinkas	Non-repudiation must be removed from out of scope list if signing purpose requirement remains Out of Scope #2 (Objects/Processing #2)	No change to requirements. Defining key usage binding does not imply full requirement for non-repudiation specification. { Resolution }
17	Jon Gunderson (03/19/2002)	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.	No change to requirements. The requirements do not specify server implementation technology. { Resolution }
18	Yassir Elley (Blair Dillaway, Stephen Farrell, Ed Simon) (02/25/2002)	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.	The following text was added to 2.1.2: "Clients and servers are not required to implement a general purpose XML parsing capability." { Resolution }
19	Al Arsenault (04/05/2002)	Precluding other authentication mechanisms in 2.5.9.	Last sentence of 2.5.9 removed, modified slightly, and added to out of scope as follows: Defining authentication mechanisms. While there's no technical reason for this, it's just to limit the scope of the WG to what's necessary.
20	Frederick J. Hirsch	Change requirement for introspection from MUST to MAY 2.3.1	Changed 2.3.1 to "A Server MAY be deployed that implements a subset of XKMS service functionality, such as Locate but not Validate for example.". This revision is based on discussion at the F2F. {Resolution, Minutes Editors issues - I}
21	Al Arsenault (04/05/2002)	Key recovery (2.4.4): Concern that this will be a mandatory feature.	No change to requirements. Only mandatory for the spec to describe, not for implementations to support.
22	Al Arsenault (04/05/2002)	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 change to requirement. The specification must ensure that this option is not precluded. One way to do this is for the specification to demonstrate how it can be done.
23	Denis Pinkas	Defer XML extensions to future, enable interoperability Formats #11	No change to requirement. By using XML namespaces and XML extensibility we can retain extensibility now without damaging interoperability. { Resolution }
24	Shivaram H. Mysore	Qualify/Define "excessive overhead" when passing requests from one server to another 2.1.12	Changed wording as discussed at F2F to use phrase "minimal overhead". {Resolution, Minutes Editors issues - L}

Clarifications

#	Source	Issue	Resolution
25	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. Revised 2.1.7, 2.1.8, 2.2.4, 2.2.8, 2.2.12, 2.3.3, 2.3.4, 2.4.21 {Resolution , Minutes Issue 6}
26	Denis Pinkas	Add a definition for "Key Location Service"	Added Key Location definition. { Resolution }
27	Denis Pinkas	Make explicit that encapsulated PKIX structures such as Certificates, CRLs etc are allowed in XML definitions Universality+Usability item 2	Added wording to 2.1.2: "Note that common PKIX structures such as X.509 certificate and CRL structures may be embedded as binary (base64 encoded) data within XML elements as indicated by the KeyInfo definition [ XMLDsig ]." { Resolution }
28	Frederick J. Hirsch	Add language that applications which deal with X.509 certificates will require ASN.1 processing capability.	Added to previous (2.1.2) wording, "Applications which expect to process X.509 certificates will require ASN.1 and certificate processing capabilities." Added 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 able to manage the details." {Resolution}
29	Denis Pinkas	Separate validation/status check items from registration and revocation Capabilities #8, #9	Established separate sections in Protocol Capabilities and Formats section for XKRSS and XKISS. { Resolution }
30	Denis Pinkas	Can only validate binding, not public key Capability #8	{ Resolution }
31	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	Updated 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." { Resolution }
32	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	We revised Requirement 2.2.1 to clarify that servers are required to support TLS and payload security and may opt to support IPSec. We think this captures the intent of the original requirement without the wording of "no security" in the previous version. {Resolution, Minutes Issue 9}
33	Shivaram H. Mysore	Revise definition of Proof of Possession	Revised wording. "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." {Resolution}
34	Shivaram H. Mysore	Status of Document formatting: (Activity Statement) -> [Activity Statement] pubicly -> publicly	removed in editors draft, 18 Feb 2002. {Resolution}
35	Shivaram H. Mysore	Add reference to Activity Statement in References	Added Activity statement reference. {Resolution}
36	Shivaram H. Mysore	Revise goal statement in introduction	Revised wording of 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 to be consistent with the Security Assertion Markup Language [SAML]. {Resolution}
37	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).	Add the following to the end of paragraph 1 of Section 1: "XML key management services will primarily be of interest to clients that intend to communicate using XML-based protocols bound to SOAP. It may be that such clients will not have sufficient ASN.1 capabilities (though possibly not as noted above), in which case the benefits of offloading the parsing of certificates and other traditional PKI structures (e.g. CRLs or OCSP responses) is clear. Clients which possess such capabilities and have no preference to work with XML-based protocols may opt to use non-XML-based protocols defined by [PKIX], for example." {Minutes, Editors issues - O}
38	Shivaram H. Mysore	Reword Asynchronous Exchange example.	Revised wording. "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." {Resolution}
39	Yassir Elley	Replace "PX509" with "X509"	Revised wording. "...if the service claims interoperability with PKIX X.509." { Resolution }
40	Yassir Elley	client->clients 2.1.7	Revised wording. "Usability and simplicity are paramount to enable clients to obtain ..." { Resolution }
41	Yassir Elley	fix fragment 2.2.3	Revised wording. "In particular, the specification MUST define how transport layer security such as SSL/TLS is to be used." { Resolution }
42	Frederick Hirsch (03/13/2002)	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/	Revised wording. {Resolution}
43	Liam Quin (03/18/2002)	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. Several requirements identify this distinction already. For example, 2.1.2 highlights the use of XML for messages and data structures, while 2.5.4 notes the key values. { Resolution }
44	Liam Quin (03/18/2002)	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 and Key Management { Resolution }
45	Shivaram H. Mysore (04/10/2002)	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	Revised wording. {Resolution}
46	Al Arsenault (04/05/2002)	Clarifications: (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.	Revised wording.
47	Al Arsenault (04/05/2002)	(2.2.3) Clarifications: The second "sentence" in this item isn't a sentence. What's missing? Should it say something like "In particular, the specification MUST define how the use of transport layer security such as SSL/TLS can be used to protect XML Key Management messages"?	In item 2.2.3, s/how the use of transport layer security such as SSL/TLS can be/define how transport layer security such as SSL/TLS is to be used.
48	F2F	Add 4 corner model reference	Added reference to 4 corner model (Identrus)
49	post-F2F (editors)	Add WSDL, UDDI, XTAML references	Added references.
50	post F2F (editors)	Fix 2.2.7 to make a real requirement rather than requiring the spec to require...	Revised wording.
51	post F2F (editors)	Clarify 2.4.10	We removed the repetition in 2.4.10 while retaining the essence.
52	post F2F (editors)	Clarify scope of requirements	We added a sentence at the end of the introduction: "This specification provides requirements for XML key management consistent with these goals, including requirements on the XML key management specification, server implementations and the protocol messages."
53	post F2F	Fix links and XHTML	Fixed.

Issues Raised After 1st Last Call

#	Source	Issue	Resolution

Issues Raised in Candidate REC

#	Source	Issue	Resolution

Last $Revision: 1.1 $ by $Author: smysore $ on $Date: 2002/05/23 18:55:19 $ GMT