XML Key Management Service WG Requirements Last Call Comments
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
| 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?) 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. |
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? 2.4.5 |
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 (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. |
(Since TLS is a commonly deployed solution
it deserves clear mention in the expectation of its use?) |
| 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. |
? |
| 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 (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. |
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) (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. |
Add to 2.1: The specification MUST NOT require that devices need to support a general purpose XML parsing capability. |
| Al Arsenault (04/05/2002) |
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 2.3.1 |
Change 2.3.1. as follows: s/Provide server introspection/Trust servers MAY provide introspection |
| Al Arsenault (04/05/2002) |
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 (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 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 2.1.12 |
"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 |
client->clients 2.1.7 |
"Usability and simplicity are paramount
to enable clients to obtain ..." |
| Yassir
Elley |
fix fragment 2.2.3 |
"In particular, the specification MUST
define how transport layer security such as SSL/TLS is to be used." |
| 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/ |
Make proposed changes. |
| 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. |
| 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: 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 (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 |
Make proposed changes. |
| Yassir
Elley (02/14/2002) |
Minor changes: (2.1.7) s/client/clients (2.2.3) Remove "how" |
Make proposed changes. |
| 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. |
|
| Source | Issue | Resolution |
| Source | Issue | Resolution |
Last $Revision$ by $Author$ on $Date$ GMT
=======