W3C XKMS Ver. 2 Last Call Working Draft Issues

Inside: Issue summary | State description | Decision cycle description | Issue details (Validate data)

This is the Disposition of Comments for the Last Call XKMS Working Drafts:

XML Key Management Specification (XKMS) Version 2.0

XML Key Management Specification (XKMS) Version 2.0 Bindings

Issue summary (72 issues)

Reformat summary with options:
Expert mode options
Hide columns:
Hide issues by type:
Hide issues by state:
Hide issues by acknowledgment:

Other views: types | states | concerning | reviewers | open actions

Changes between dates (YYYY-MM-DD) and [Optional]

For maintainers: new issue data | new issues list data

Color key: error warning note

Id:Title StateTypeAck.
301-ji-1 : SOAP Binding and use of SOAP 1.2agreedproposalNo reply from reviewer
301-ji-2 : Examples for XKMS Request and Response messages incorrectagreededitorialNo reply from reviewer
302-rzuccherato-1 : Addition of DelegatedSignature value to KeyUsage ElementdisagreedrequestNo reply from reviewer
303-dpinkas-1 : Use of distinguished namesno decision
(deferred)
clarification
303-dpinkas-2 : Obtaining information about certificates rather than about keysno decision
(deferred)
clarification
303-dpinkas-3 : Use of Certification Policy in XKMSno decision
(deferred)
clarification
303-dpinkas-4 : Typo in X-KRSS service nameagreededitorialNo reply from reviewer
303-dpinkas-5 : Ambiguity in choosing a public key shared among certificatesno decision
(deferred)
clarification
303-dpinkas-6 : make <ds:KeyInfo> always be cryptographically bounded to the signatureno decision
(deferred)
clarification
303-dpinkas-7 : XKISS Validate should verify binding with a certificateno decision
(deferred)
clarification
303-dpinkas-8 : The overviews from sections 1.5 and 1.6 are not cleardisagreededitorialNo reply from reviewer
303-dpinkas-9 : Add more normative text and move examples to an informative annexdisagreededitorialNo reply from reviewer
303-dpinkas-10 : Menaing of "resolving <ds:Keyinfo> element"disagreededitorialNo reply from reviewer
303-dpinkas-11 : Should X-KISS return a certificate?no decision
(deferred)
clarification
303-dpinkas-12 : Unclear definition of X-KISS validateno decision
(deferred)
clarification
303-dpinkas-13 : X-KISS Validate returns proof of binding a certificate, not to a keyno decision
(deferred)
editorial
303-dpinkas-14 : Unclar exampledisagreededitorialNo reply from reviewer
303-dpinkas-15 : XKISS Validate should include the concept of RFC 3379 "validation policy"disagreedclarificationNo reply from reviewer
303-dpinkas-16 : Service discovery for XKMS servicesdisagreedclarificationNo reply from reviewer
303-dpinkas-17 : Lack of support for validation policyno decision
(deferred)
clarification
303-dpinkas-18 : Uniqueness of key identifierno decision
(deferred)
clarification
303-dpinkas-19 : Define key usages in terms of security services, non-repudiation keysdisagreedclarificationNo reply from reviewer
303-dpinkas-20 : Meaning of subject identifier within the <UseKeyWith> elementdisagreedclarificationNo reply from reviewer
303-dpinkas-21 : No mention of CMS as a protocoldisagreedclarificationNo reply from reviewer
303-dpinkas-22 : Why do you consider PKIX a protocol?disagreedclarificationNo reply from reviewer
303-dpinkas-23 : Use of "Certificate Subject Name" as an identifierdisagreedclarificationNo reply from reviewer
303-dpinkas-24 : Include a quote about XAdESagreededitorialNo reply from reviewer
303-dpinkas-25 : The description of the XKISS Validate service is confusingdisagreedclarificationNo reply from reviewer
303-dpinkas-26 : Values returned by the XKISS Validate servicedisagreedclarificationNo reply from reviewer
303-dpinkas-27 : Consider adding a "not valid yet" response to the XKISS Validate servicedisagreedclarificationNo reply from reviewer
303-dpinkas-28 : Incomplete definition of the XKRSS Register servicedisagreedclarificationNo reply from reviewer
303-dpinkas-29 : Mapping of "UseKeyWith Application" with X.509 certificatesdisagreedclarificationNo reply from reviewer
303-dpinkas-30 : Use of out-of-band information in the XKRS Register servicedisagreedclarificationNo reply from reviewer
303-dpinkas-31 : Differences between Reissue and Register requestsno decision
(deferred)
clarification
303-dpinkas-32 : The Revocation request should allow to specify a reason code and an invalidate dateno decision
(deferred)
clarification
303-dpinkas-33 : Requesting a Revocation without quoting the certificatedisagreedclarificationNo reply from reviewer
303-dpinkas-34 : The Recovery request is different from the Registration servicedisagreedclarificationNo reply from reviewer
303-dpinkas-35 : Expand the security considerations issue to indicate more limitationsno decision
(deferred)
editorial
304-cadams-1 : Two Phase Protocol and <Result> elementdisagreedclarificationNo reply from reviewer
304-cadams-2 : Section 3.3.2: Element <RequestSignatureValue>agreededitorialNo reply from reviewer
304-cadams-3 : Section 6.1.1 Example: Registration of Client Generated KeyPairagreedclarificationNo reply from reviewer
304-cadams-4 : Section 6.1.2 Example: Registration of Service Generated KeyPairagreedclarificationNo reply from reviewer
305-jreagle-1 : Flow/Organization of the DocumentagreededitorialNo reply from reviewer
306-rlockhart-1 : Schema Error - CompoundResultagreederrorNo reply from reviewer
307-asanin-1 : No way to specify the desired key type for LocateRequestdisagreededitorialNo reply from reviewer
307-asanin-2 : Use of Symmetric KeysdisagreedrequestNo reply from reviewer
307-asanin-3 : ValidityInterval does not have optional attribute specifiedagreederrorNo reply from reviewer
307-asanin-4 : Change KeyUsage attribute maxOccurs to use unbounddisagreedrequestNo reply from reviewer
308-ykhan-1 : Section 4.2.1 Example: Document Signature incorrect ValidateResponseagreederrorNo reply from reviewer
309-ykhan-1 : Section 2.5.2: Pending Request and Response Examples incorrectagreederrorNo reply from reviewer
309-ykhan-2 : Use of # Before Id Values in XKMS responseSubsumedclarificationNo reply from reviewer
310-smysore-1 : TyposagreededitorialNo reply from reviewer
310-smysore-2 : Typos - Protocol Bindings SpecdisagreededitorialNo reply from reviewer
311-dchopra-1 : Use of Requester and Responder instead of Sender and ReceiverdisagreededitorialNo reply from reviewer
311-dchopra-2 : Use Pending instead of AsynchronousagreededitorialNo reply from reviewer
311-dchopra-3 : Section 2.4.1 - Use of Asynchronous in RespondWithagreedclarificationNo reply from reviewer
311-dchopra-4 : Section 2.5 -PendingRequestagreedclarificationNo reply from reviewer
311-dchopra-5 : Section 2.5.1 -Value of RespondWithagreederrorNo reply from reviewer
311-dchopra-6 : Section 2.5.3.5 -Value of RequestIDagreederrorNo reply from reviewer
311-dchopra-7 : Difference between Asynchronous processing and 2 phase protocolagreedclarificationNo reply from reviewer
311-dchopra-8 : Is nonce requiredagreedclarificationNo reply from reviewer
311-dchopra-9 : Who can handle CompoundRequests?agreedclarificationNo reply from reviewer
311-dchopra-10 : Section 3.2.4agreededitorialNo reply from reviewer
311-dchopra-11 : Fix types for OriginalRequestID, RespondID, RequestIDSubsumederrorNo reply from reviewer
311-dchopra-12 : AuthenticationdisagreedclarificationNo reply from reviewer
311-dchopra-13 : Add details to CompoundRequest as per schemaagreededitorialNo reply from reviewer
311-dchopra-14 : UseKeyWith IdentifiersdisagreedclarificationNo reply from reviewer
311-dchopra-15 : Bindings Doc: Section 3.1disagreedclarificationNo reply from reviewer
311-dchopra-16 : Bindings Doc: Soap fault error codes and use of Requester and ResponderdisagreedclarificationNo reply from reviewer
311-dchopra-17 : Bindings Doc: Where is the 3rd security binding?agreederrorNo reply from reviewer
312-dchopra-1 : Fix types for OriginalRequestID, RespondID, RequestIDagreederrorNo reply from reviewer
312-ykhan-2 : Use of # before Id Values in XKMS responseagreedclarificationNo reply from reviewer

State description

Decision cycle description

Issue details

301-ji-1: SOAP Binding and use of SOAP 1.2 [link to this issue]

1. Section 3 SOAP Binding
para [41] The paragraph includes the sentences:

"Use of SOAP 1.1 is REQUIRED by implementers in the near term for
compatibility with existing tools
and infrastructures. Use of SOAP 1.2 is Recommended."

The XKMS requirements document includes the requirement that :

   XKMS services MUST implement SOAP 1.2 once that specification has
   achieved Candidate Recommendation status.

SOAP 1.2 has now reached Proposed Recommendation status so we ask the XKMS
WG to state that the use of SOAP 1.2 is REQUIRED by implementers. In
addition, SOAP 1.1 is W3C Note which has an informal status. The XKMS
specification should reflect this. We suggest the sentences above be
changed to:

"Use of SOAP 1.2 is REQUIRED by implementers of this specification. For
near term compatibility with existing tools and infrastructure, SOAP 1.1
MAY be used"

Transition history

raised on 13 May 2003 by John Ibbotson, on behalf of SOAP/XML Protocol
agreed on 6 Aug 2003

The changes you proposed to the specification have been accepted and the revised version of the specification may be seen at [1], Para 42.

[1] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html

Acknowledgment cycle
announced by group on 6 Aug 2003

301-ji-2: Examples for XKMS Request and Response messages incorrect [link to this issue]

2. Section 3.1.1 SOAP 1.2 Binding
The example XKMS Request and Response messages in paras [45] and [46] are
syntactically incorrect - there is no termination for the env:Header
element. Similar errors exist in the examples in paras [54] and [55].

Transition history

raised on 13 May 2003 by John Ibbotson, on behalf of SOAP/XML Protocol
agreed on 6 Aug 2003

The changes you proposed to the specification have been accepted and the revised version of the specification may be seen at [1], Para 46-47.

N.B. the par 55-56 change was missing and I added it later on. JK.

[1] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html

Acknowledgment cycle
announced by group on 6 Aug 2003

302-rzuccherato-1: Addition of DelegatedSignature value to KeyUsage Element [link to this issue]

A DSS service may produce signatures (such as XML-DSIG and CMS signatures)
for its clients - if it authenticates the client, it may attach the client's
name as a signed attribute to the signature - this way a client can produce
signatures that are associated with himself, without needing his own key
pair.

So it would be nice if a relying party can query an XKMS service on the DSS
client's name, and receive back the DSS service's key, but the XKMS client
would need to be told that this key is not in the sole possession of the DSS
client, but must be associated with the DSS client through a signed
attribute.

Two options appear feasible.  

This could be done by adding a new "DelegatedSignature" value to the
<KeyUsage> element: <KeyUsage>DelegatedSignature</KeyUsage>.  So for a given
protocol that uses signatures, an XKMS client could query for
<KeyUsage>DelegatedSignature</KeyUsage> as well as 

<KeyUsage>Signature</KeyUsage>.  This is simple, but would require a change
to XKMS.

Alternatively, the same an extra application URI could be defined for the
<UseKeyWith> element, for every protocol that uses signatures, to denote the
delegated signature version.  This requires the definition of an extra URI
for each protocol that uses signatures and thus seems more difficult to
support, in general.  It would not require a change to XKMS though.

Transition history

raised on 22 May 2003 by Robert Zuccherato, on behalf of OASIS DSS TC
disagreed on 6 Aug 2003

The DSS TC raised the issue of how one should indicate to an XKMS client that key information returned by an XKMS service was associated with a DSS service. This would indicate that the keys are in possession of the DSS service and associated with the DSS client through a signed attribute. It was suggested that a new <KeyUsage> element value or a <UseKeyWith> URI might be appropriate.

We do not believe a new <KeyUsage> element value is the correct mechanism for addressing this issue. KeyUsage is intended to identify the cryptographic operation that a key may be used for. It is not intended to indicate other factors such as how a key is stored or who has control over the key's use. Within the DSS context, the appropriate KeyUsage would be "Signature".

We recommend definition of a new <UseKeyWith> URI as the appropriate mechanism for meeting your requirements. The XKMS specification (23 July 2003 Editor's Draft), defines UseKeyWith as: "[184] The primary use intended for <UseKeyWith> identifiers is to identify application protocols. <UseKeyWith> URI identifiers MAY be specified that represent key binding issuance and/or use policies instead of or in addition to an application protocol. In this case the <UseKeyWith> element specifies that the key binding complies with the specified policy."

As we understand the objectives of the DSS TC, you are defining a use policy for a signing key. That use policy is along the lines of: signature generation is performed by an authorized DSS server and is bound to a given client via a signed attribute. Once the DSS TC has formalized this policy statement, a URI may be associated with it. The DSS TC should define this URI and incorporate it into the DSS specification. The DSS effort is not at the appropriate standards status level for a normative reference from within the XKMS specification.

Acknowledgment cycle
announced by group on 1 Aug 2003

303-dpinkas-1: Use of distinguished names [link to this issue]

The overall model is making the silent assumption that only names that 
are unique by their structure, i.e. DNS names, RFC 822 names or IP 
addresses, shall be used. Since DNS names, RFC 822 names and IP addresses 
are unique, there is no difference between such names certified by CA1 or 
CA2. If Distinguished Names (DNs) were being used, a DN certified by CA1 and 
the same DN certified by CA2 could correspond to the same or to different 
entities. XKMS currently prohibits the use of DNs or, said in other words, 
exhibits security problems if such names were being used. This should be 
clearly advertised, or a fix to this problem should be made.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
deferred on 8 Aug 2003

SF: To save some time I should preface our individual responses by saying that the wg felt that many of the comments reflect a misaphrehenshion of the goals of xkms - in particular, xkms is not intended to be an xml variant of x.509 and therefore concepts such as "CA" (etc.) do not make sense in and of themselves. That is, while it is a goal to be able to sensibly place an xkms responder "in front of" and x.509 based pki, there is no requirement that all xkms responders operate like that. It is entirely within the xkms wg's remit to consider single server, certificate-less (i.e. raw keys only) systems. This made it impossible for the wg to do other than to note many of your comments, since they could not be accepted given the wg's charter[1], which in its first sentence states:

"The mission of this working group is to develop a specification of anXML application/protocol that allows a simple client to obtain key information (values, certificates, management or trust data) from a web service."

[1] http://www.w3.org/2001/XKMS/2002/11/charter.html

Where your comments appear to require that xkms embody such x.509 concepts as "certificates", or "CAs" then we have simply referred to this preface since the wg cannot process those.

If you would care to "translate" your comments into more "xkms-friendly" terminology, then the wg would be happy to consider those after this last call process is completed.

303-dpinkas-2: Obtaining information about certificates rather than about keys [link to this issue]

A major error in XKMS is to consider to obtain information about keys, 
rather than information against certificates, which bind a public key to a 
name for a specific key usage and under a Certification Policy. Since there 
is not a one-to-one relationship between a key and a certificate, but a 
one-to-many relationship, it is not possible to make an unambiguous binding 
with a public key but only an unambiguous binding with a (public key) 
certificate.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
deferred on 8 Aug 2003

See decision for 303-dpinkas-1 issue.

303-dpinkas-3: Use of Certification Policy in XKMS [link to this issue]

The Certification Policy is a concept which seems to be ignored at the 
level of the interfaces that are being proposed.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
deferred on 8 Aug 2003

See decision for 303-dpinkas-1 issue.

303-dpinkas-4: Typo in X-KRSS service name [link to this issue]

In section [46] the text says:

"The XKMS specification defines three types of request:

X-KRSS Request
      A Register, Reissue, Revoke or Recover request as specified by the Key 
Information Service Specification".

There is indeed a typo, probably intentionally left by the editor, to make 
sure that at least someone read the specification: "Key Information Service 
Specification" should be changed into "Key *Registration* Service 
Specification".

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
agreed on 8 Aug 2003

Fixed.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-5: Ambiguity in choosing a public key shared among certificates [link to this issue]

The <ds:KeyInfo> (see [135]) is described as an "hint". This should not 
be the case since it is important to make sure under which certificate a 
signer wanted to sign. Several certificates may include the same public key 
and for that reason it is important to make sure that the certificate (or an 
unambiguous reference to it) is linked to the data that has been signed and 
is indeed protected by the signature. Without that link certificates could 
be substituted without notice. The concept is similar to ESSCertID that is 
used in CMS (see RFC 2634).

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
deferred on 8 Aug 2003

See decision for 303-dpinkas-1 issue.

303-dpinkas-6: make <ds:KeyInfo> always be cryptographically bounded to the signature [link to this issue]

The fact that <ds:KeyInfo> may or may not be cryptographically bound to 
the signature itself is advertised as an important property (see [136]). It 
is said: "This allows the <ds:KeyInfo> to be substituted or supplemented 
without "breaking" the digital signature". This should be considered as a 
severe weakness, since such a substitution is not desirable (see above). A 
certificate could be added, but the reference to the certificate should 
remain unchanged and unchangeable.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
deferred on 8 Aug 2003

See decision for 303-dpinkas-1 issue.

303-dpinkas-7: XKISS Validate should verify binding with a certificate [link to this issue]

The XKISS Validate service verifies a binding with a public key, while 
the binding should be verified with a certificate (which contains a public 
key), instead of directly a public key value. CAs may deliver different 
certificates with the same public key but with different attributes in them. 
It is important to know which certificate has been used, rather than which 
public key has been used, since several certificates may include the same 
public key.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
deferred on 8 Aug 2003

See decision for 303-dpinkas-1 issue.

303-dpinkas-8: The overviews from sections 1.5 and 1.6 are not clear [link to this issue]

The two overviews from sections 1.5 and 1.6 do not provide a clear 
picture of the functions that are supported. They should be both revised. A 
text is proposed as an annex at the end of these comments.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

The WG felt that the current text was sufficient.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-9: Add more normative text and move examples to an informative annex [link to this issue]

The document provides several examples which are quite interesting. 
However the core of a standard should not include examples. Such examples 
should be placed in an annex. However if these examples were removed the 
text would not be understandable anymore, because the remaining explanations 
would be insufficient. It is thus requested to add more normative text and 
to move the examples in an informative annex.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

The WG has attempted to match the style from previous standards like XKMSIG and SAML.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-10: Menaing of "resolving <ds:Keyinfo> element" [link to this issue]

The XKISS Locate service is defined as " The XKISS Locate service 
resolves a <ds:Keyinfo> element but does NOT REQUIRE the service to make an 
assertion concerning the validity of the binding between the data in the 
<ds:Keyinfo> element". What means "resolving <ds:Keyinfo> element" is not 
self-understandable. The exact processing that is supposed to be done by the 
service should be described in details.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-11: Should X-KISS return a certificate? [link to this issue]

The example (see [145]) is insufficient to describe what that service 
really does. The various input (and output) parameters should be clearly 
described. This is not the case.

The service seems to return only a key value, while it should return the 
main components from a certificate.

 From the example, it can be seen that the input parameters are a DNS name 
and the name of a protocol. Since no key usage is mentioned, the service is 
unable to know whether a certificate that includes a signature verification 
key or includes an encryption key is requested. A certificate should be 
returned and not a key, so that the user can verify the validity period of 
the certificate, otherwise a validity date should be included in the 
request. The certification policy contained in the certificate may also be 
helpful, unless it is specified in the request.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
deferred on 8 Aug 2003

See decision for 303-dpinkas-1 issue.

303-dpinkas-12: Unclear definition of X-KISS validate [link to this issue]

The XKISS Validate service is defined as : "The XKISS Validate Service 
allows all that the Locate Service does, and in addition, the client may 
obtain an assertion specifying the status of the binding between the public 
key and other data, for example a name or a set of extended attributes". 
What means "other data" is not self-understandable. The exact processing 
that is supposed to be done by the service should be described in details.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
deferred on 8 Aug 2003

See decision for 303-dpinkas-1 issue and the response to 303-dpinkas-10.

303-dpinkas-13: X-KISS Validate returns proof of binding a certificate, not to a key [link to this issue]

In [152] it is mentioned: "Furthermore the service represents that the 
status of each of the data elements returned is valid and that all are bound 
to the same public key". A <ds:Keyinfo> element may contain a <ds:X509Data>
element. Therefore the binding is not with a key but with a certificate.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
deferred on 8 Aug 2003

See decision for 303-dpinkas-1 issue.

303-dpinkas-14: Unclar example [link to this issue]

The example (see [155]) is insufficient to describe what that service 
really does. The various input (and output) parameters should be clearly 
described. This is not the case.
In particular, is the validation done only for the current time or can it be 
done for a time in the past ? Even, if this is the current time, is that 
time indicated in the response? The answer is only given (hidden) in section 
[215], but this should be clearly advertised upfront.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

The WG felt that the current section was sufficient.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-15: XKISS Validate should include the concept of RFC 3379 "validation policy" [link to this issue]

From its name, the XKISS Validate Service present a few similarities 
with the validation service requirements that have been defined by the PKIX 
WG from the IETF. This working group has produced RFC 3379 (Delegated Path 
Validation and Delegated Path Discovery Protocol Requirements) which is a 
set of requirements.

However, the XKMS specification is leaving aside many, if not most, of the 
these requirements. An important concept from RFC3379 is the concept of 
"validation policy". When a validation is done, it must be done according to 
a set of rules. These rules depends upon the application. In particular some 
root keys may be adequate for an application, but not for another. Trust 
elements cannot be uniform and cannot be left open to the Validate Server.

The text is speaking of a "validation criteria (see [161]), but it is 
unclear what it really is. This is one of the most severe limitations of 
XKMS and this limitation is not advertised.

It would be quite interesting to understand why the requirements from 
RFC3379 have not been followed.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

xkms is a W3C activity and as such there is no onus on the group to take account of works-in-progress from elsewhere. However, as you say, there is a similarity with the on-going pkix work on on-line services. The WG has produced its own requirements document, which differs from rfc3379, and which was finalised well before rfc 3379. We would indeed be interested were someone to compare those documents, but the WG has no intention of doing so at present.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-16: Service discovery for XKMS services [link to this issue]

The text is speaking of some means to locate the correct XKMS service 
(see [163]) but does not provide any guidance in order to solve this 
problem, in particular in the context of multiple servers offering their 
services to the users.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

The WG decided to omit this from its scope, given that W3C is also working on other mechanisms for service discovery.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-17: Lack of support for validation policy [link to this issue]

The text in [168] states: "the Service represents to the client 
accessing the service and to that client alone that the binding between the 
data elements is valid under whatever trust policy the service offers to 
that client." Unless the service can clearly advertise which trust policy is 
being used, the client cannot use any kind of trust policy without even 
knowing which one it is. As already stated, the concept of validation policy 
is not supported, but should be supported.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
deferred on 8 Aug 2003

See decision for 303-dpinkas-1 issue.

303-dpinkas-18: Uniqueness of key identifier [link to this issue]

The text under [171] mentions: "The Id identifier is defined to provide 
a means by which the key binding may be signed using XML Signature. Clients 
MUST NOT rely on the key binding identifier being either unique or stable". 
On the contrary it is believed that a key identifier should be unique. The 
ESSCertID from RFC 2634 is a good example of such a unique binding.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
deferred on 8 Aug 2003

See decision for 303-dpinkas-1 issue.

303-dpinkas-19: Define key usages in terms of security services, non-repudiation keys [link to this issue]

The text under [174] considers only three intended uses of the key:

   1) Encryption : The key pair may be used for encryption and decryption,
   2) Signature : The key pair may be used for signature and verification,
   3) Exchange: The key pair may be used for key exchange.

However, the key usages should be defined in terms of security services (see 
ISO 7498-2), i.e. authentication service, confidentiality service and 
non-repudiation service.

To avoid some security problems it is particularly important to make a 
difference between a key usable for authentication and a key usable for 
non-repudiation. This cannot be covered by a single key usage called 
"signature".

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

The wg explicitly decided not to tackle issues to do with repudiation using the key usage mechanism.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-20: Meaning of subject identifier within the <UseKeyWith> element [link to this issue]

The text under [177] mentions the <UseKeyWith> element which specifies a 
subject identifier and application identifier that determine a use of the 
key. The <UseKeyWith> must contain "Application" which is a URI that 
specifies the application protocol with which the key may be used and 
"Identifier" which specifies the subject to which the key corresponds within 
the specified application protocol. A protocol can support a sender and a 
receiver. It is unclear whether the Identifier corresponds to the sender or 
the receiver. It seems that the notion is by itself insufficient and should 
be extended to make such difference.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

UseKeyWith is intended to be extensible. A protocol where the sender/recipient distinction is required can define its own variant UseKeyWith URI.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-21: No mention of CMS as a protocol [link to this issue]

The text under [180] mentions S/MIME as a protocol. Why is CMS 
(Cryptographic Message Syntax) not considered as a protocol as well ?

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

CMS is used much more broadly. The wg felt happy to define the identifier for s/mime but not for all cms based protocols

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-22: Why do you consider PKIX a protocol? [link to this issue]

The text under [180] mentions PKIX. It is very unclear to understand why 
PKIX is considered as a "protocol" since it is only a set of data structures.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

The intent was to define the identifier and uri for protocols which abide by "pkix rules".

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-23: Use of "Certificate Subject Name" as an identifier [link to this issue]

The text under [180] mentions the use of "Certificate Subject Name" as 
an appropriate identifier. It should be observed that this name only is 
insufficient to correctly identify an entity, since two CAs may certify the 
same name and that this name may correspond to the same or to different 
entities. Unless a sequence of CAs names is added to the entity name up to a 
root key, such names are ambiguous. This relates to the non-uniqueness of DN 
names already mentioned.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

The wg felt that a single name was sufficient. A service deployment which faces that challenge might define something else.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-24: Include a quote about XAdES [link to this issue]

The text under [180] identifies various protocols. To this list, XAdES 
(XML Advanced Electronic Signature) which is a W3C Note issued on February 
20, 2003 should be added (see: http://www.w3.org/TR/XAdES/). The 
"identifier" type is such a case is a SigningCertificate element, i.e. *not* 
a DN.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
agreed on NaN Dec 2003

JK: After later discussions, the following paragraph was added to the XKMS part-1 spec:

[184] The primary use intended for <UseKeyWith> identifiers is to identify application protocols. <UseKeyWith> URI identifiers MAY be specified that represent key binding issuance and/or use policies instead of or in addition to an application protocol. In this case the <UseKeyWith> element specifies that the key binding complies with the specified policy. For example, applications handling XAdES [XAdES] compliant signatures could define their own <UseKeyWith> application values.
Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-25: The description of the XKISS Validate service is confusing [link to this issue]

The description of the Validate Service are confusing. It seems to 
relate more to the Locate Service rather than the Validate Service where the 
primary response should be "valid according to some policy" or "invalid 
according to some trust policy". The exact service performed by the Validate 
Service is not sufficiently detailed.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

The WG felt otherwise.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-26: Values returned by the XKISS Validate service [link to this issue]

In [221] it is mentioned: "The server returns one or more <KeyBinding>
elements that meet the criteria specified in the request." It is 
questionable why not simply a valid, invalid or don't know assertion is made 
against the proposed binding.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

The service is free to return additional information.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-27: Consider adding a "not valid yet" response to the XKISS Validate service [link to this issue]

In the case of validation, the "yet not valid" response should be 
considered, in particular when a certificate is suspended. This means that 
another validation request made later on may succeed.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

(We assume you meant "not valid yet".) The wg didn't feel that this was of sufficient interest to warrant inclusion at this point.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-28: Incomplete definition of the XKRSS Register service [link to this issue]

The Register Service from KRSS is not sufficiently described. The two 
examples provide more information, but that information is not normative. 
 From the example, two features are mentioned:

1. authentication information to be used later on for revocation can be 
transmitted. However, it is unfortunate that the data does not also include 
the question to be answered.

2. it is necessary to have a face to face contact with the LRA before being 
able to use the register request. During that face to face information is 
captured by the LRA and the secret "authentication code" is provide to the 
end-user. However, this method is time consuming and does not allow a cost 
effective deployment of a PKI.

It is suggested to use another technique that places all the burden of the 
typing for the end-user, who receives back both a registration number and 
the hash of his request (signed by the service) so that the end-user can 
then authenticate to the LRA in a face to face where the Register Service 
has only to verify the information (and to only "click" to accept or 
reject). Another advantage is that no secret information is being used.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

The WG felt that the current text was fine, given, as you say, that they are examples.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-29: Mapping of "UseKeyWith Application" with X.509 certificates [link to this issue]

In the example [241] several identifiers are included :

<UseKeyWith Application="urn:ietf:rfc:2459"
Identifier="C="US" O="Alice Corp"
CN="Alice Aardvark""/>
<UseKeyWith Application="urn:ietf:rfc:2633"
Identifier="alice@alicecorp.test"/>
<UseKeyWith Application="http://ca.example.com/cps/20030401/class3"
Identifier="alice@alicecorp.test"/>

It is unclear to understand how the concept of "UseKeyWith Application" will 
be translated in an X.509 certificate, since an X.509 certificate does not 
support the concept of "UseKeyWith Application".

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

There is no direct equivalent of UseKeyWith in x.509. The wg has no requirement to be compatible with everything in x.509, nor vice versa. In this case, probably the most common thing will be for services to map between UseKeyWith and various x.509 extensions (in particular some policy oids) with the help of local configuration. The wg felt that such mappings were easier done locally.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-30: Use of out-of-band information in the XKRS Register service [link to this issue]

In the example [245] the private key is returned in the response. It 
will be quite uneasy for the end-user to memorize the authentication code 
3n9cj-jk4jk-s04jf-20934-jsr09-jwik4 previously obtained through some 
out-of-band mechanism. This method would be quite difficult to use and would 
not allow an easy and cost effective deployment of a PKI. It is suggested to 
use another technique that allows the end user to locally generate a key 
pair, so that the public key can be sent in the Register Service request and 
then used by the Register Service to encrypt the private key once generated. 
The main advantage is that no secret information is being used and no 
out-of-bands mechanism is necessary.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

The WG felt that the example is sufficient.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-31: Differences between Reissue and Register requests [link to this issue]

The Reissue request mentions "A reissue request is made in the same 
manner as the initial registration of a key". It is not believed that this 
statement is correct. The user should provide the previously obtained 
certificate and ask for another validity period. There is no need to specify 
again secret information obtained through an out of bands mechanism.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
deferred on 8 Aug 2003

See decision for 303-dpinkas-1 issue.

303-dpinkas-32: The Revocation request should allow to specify a reason code and an invalidate date [link to this issue]

The Revocation request should allow the possibility to carry a reason 
code and an Invalidity Date (RFC 2459 states that CRL issuers are strongly 
encouraged to include meaningful reason codes in CRL entries).

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
deferred on 8 Aug 2003

See decision for 303-dpinkas-1 issue.

303-dpinkas-33: Requesting a Revocation without quoting the certificate [link to this issue]

The Revocation request example includes the certificate. It is very 
doubtful that the user will be able to provide its full certificate, if his 
smart card has been stolen. However he could more easily provide his subject 
name instead. The input and the output parameters are not sufficiently 
described.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

The WG felt that the example text was sufficient.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-34: The Recovery request is different from the Registration service [link to this issue]

The Recovery request mentions "A key recovery request is made in the 
same manner as the initial registration of a key". It is not believed that 
this statement is correct. There is no need to specify again secret 
information obtained through an out of bands mechanism.
Users do not have only a confidentiality key, but also an authentication 
key. They could use it to authenticate. If they loose everything, they could 
encrypt the authentication code under a key they wish their private key to 
be recovered (using PKCS#12) and authenticate their request by phone using 
the non-secret registration number of their request. For this to be 
possible, a hash of the request should be present in the response.

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
disagreed on 8 Aug 2003

"In the same manner" does not mean *exactly* the same, just similar, so the WG feels that the text is fine.

Acknowledgment cycle
announced by group on 8 Aug 2003

303-dpinkas-35: Expand the security considerations issue to indicate more limitations [link to this issue]

The security considerations section should be augmented to mention the 
severe limitations that are indicated above (JK: in the previous 34 issues).

Transition history

raised on 7 May 2003 by Denis Pinkas, on behalf of IETF
deferred on 8 Aug 2003

See decision for 303-dpinkas-1 issue.

304-cadams-1: Two Phase Protocol and <Result> element [link to this issue]

# 1. Section 2.6: Two Phase Request Protocol. As far as I can tell from the text, the purpose of the two phase protocol and the nonce is for the service to protect itself against Denial of Service attacks and against replay attacks. So why is it sensible to make the client trigger this by including "Represent" in the first request message? How does the client know that the service will want to do this?
On p.15 it says that if the service requires use of the two phase protocol and the requester did not put "Represent" in the request, then the service is to return a MajorResult of "Receiver" and a MinorResult of "MustRepresent". This logic seems odd -- almost as if the service is returning an error for a badly-formed request (even though the requester can't have known beforehand that this was needed). It would be preferable, I think, to simply send the regular response with a MajorResult of "Represent"; if the requester can't deal with this, then *it* should send the error message.
# Section 3.3.1: Element . Related to the previous comment, I'll just note that if you want to keep the interchange the way it is currently specified then you need to add a MinorResult of "MustRepresent" to the second table in 3.3.1.1.

Transition history

raised on 16 May 2004 by Carlisle Adams , on behalf of XKMS
disagreed on 5 Aug 2003

The work group agreed that item 1 is a reasonable point, but that we should stay with our current approach since it works, even though is different.

Acknowledgment cycle
announced by group on 5 Aug 2003

304-cadams-2: Section 3.3.2: Element <RequestSignatureValue> [link to this issue]

3. Section 3.3.2:  Element <RequestSignatureValue>.  The last line of the
first paragraph says, "This provides a cryptographic linkage between the
request and the response."  Note that it's only a "cryptographic linkage" if
the response is signed or cryptographically protected in some other way.
The conditions in the remainder of the section do not say this.

Transition history

raised on 16 May 2004 by Carlisle Adams, on behalf of XKMS
agreed on 5 Aug 2003

MinorResult error code of RepresentRequired was added to the latest draft in section 3.3.1.1 line 122 - see [2]

[2] Section 3.3 latest draft: http://www.w3.org/2001/XKMS/Drafts/XKMS-20030723/#XKMS_2_0_LC3_Section_3_3

Acknowledgment cycle
announced by group on 5 Aug 2003

304-cadams-3: Section 6.1.1 Example: Registration of Client Generated KeyPair [link to this issue]

4. Section 6.1.1:  Example: Registration of Client-Generated Key Pair.  In
the <KeyBindingAuthentication> element, there is no key identifier.  How is
the service supposed to know which key to use to verify this binding?  Is it
supposed to be implied from the <UseKeyWith> elements in
<PrototypeKeyBinding>?  If so (or if there's some other way that the service
is supposed to figure this out), shouldn't this be specified somewhere so
that implementers know what to build?

Transition history

raised on 16 May 2004 by Carlisle Adams, on behalf of XKMS
agreed on 5 Aug 2003

this is fixed with the following text at line 123 in the latest draft [2]: "If the response is signed this provides a cryptographic linkage between the request and the response."

There is no key identifier in a key authentication signature because the key is specified by the key authentication type. A proof of possession can ONLY be authenticated by the subject key. Similarly for the symmetric authentication mode. Leaving out the key identifiers deliberately prevents the possibility of error, checking against the wrong key.

[2] Section 3.3 latest draft: http://www.w3.org/2001/XKMS/Drafts/XKMS-20030723/#XKMS_2_0_LC3_Section_3_3

Acknowledgment cycle
announced by group on 5 Aug 2003

304-cadams-4: Section 6.1.2 Example: Registration of Service Generated KeyPair [link to this issue]

5. Section 6.1.2:  Example: Registration of Service-Generated Key Pair.  The
third paragraph talks about encrypting the returned private key using a
symmetric key derived from the authentication code and includes the
following text:  "as described in Appendix C.1.3".  But Appendix C.1.3 does
not describe this process in any way.  What should be said is "as described
in Section 8.1; see also Appendix C.1.3".  [As an aside, was the key
derivation algorithm in Section 8.1 created for the purposes of this
specification?  Are there not standard ones out there (e.g., in FIPS, ANSI,
etc.) that could have been used instead?]

Transition history

raised on 16 May 2004 by Carlisle Adams, on behalf of XKMS
agreed on 6 Aug 2003

proposal to change the text in 6.1.2 to say "as described in Section 8.1; see also Appendix C.1.3". This change has been made to the latest draft at line 248, [3]

The key derivation algorithm is carried over from v1.0 of the specification and to the best of the working group's knowledge there is no substantive issue with it, apart from the fact that it is not one of the recently developed standards. The work group discussed this point and believes it is appropriate not to make a change, maintaining compatibility with v1.0.

[3] Section 6.1 latest draft: http://www.w3.org/2001/XKMS/Drafts/XKMS-20030723/#XKMS_2_0_LC3_Section_6_1

Acknowledgment cycle
announced by group on 6 Aug 2003

305-jreagle-1: Flow/Organization of the Document [link to this issue]

While the spec has improved a great deal, I've been hoping that folks new to 
the spec might be able to substantiate my lingering sense that the document 
doesn't flow as smoothly as it might. Since I'm familiar with the spec I 
don't completely trust my assessment but I was thinking:

a. Section 1 says there are two "service specifications" but doesn't say 
where they are more fully described or specified. Forward references?
b. The sections in section 1.7 do not correspond to the sections of the 
table of contents.
c. Section 1.5 has the same title as Section 4 (except that it has 
"specification"). How to make this flow better, or at least use the term (r 
not)  "specification" consistently.
d. Generally, I don't distinguish between a "message format" and a "message 
syntax." What do these section do differently?

I'm sure this is the result of our splitting/combinding documents, but we're 
to the point now where what we are doing is quite clear, and now we need to 
smooth out the flow. Consequently, I suspect we could improve the spec if 
we (1) kept in mind the progressive rendering of (description, example, 
specification), (2) had carefully considered section titles and (3) further 
nudged the reader along with "this section does blah blah blah, how blah 
blah blah is transported is in the following section foo foo foo"

Transition history

raised on 12 May 2004 by Joseph Reagle, on behalf of XKMS
agreed on 6 Aug 2003

The changes you proposed to the specification have been accepted Issue a - added forward links to the sections that describe protocolsIssue b - Fixed - see para 36issue c - Fixed - See Section 1.5, 4Issue d - Fixed - Section 2 is now protocol exchanges

Acknowledgment cycle
announced by group on 6 Aug 2003

306-rlockhart-1: Schema Error - CompoundResult [link to this issue]

I think there are 2 errors in the XKMS last call schema at
http://www.w3.org/TR/2003/WD-xkms2-20030418/Schemas/xkms.xsd
<http://www.w3.org/TR/2003/WD-xkms2-20030418/Schemas/xkms.xsd> :

1. The choice of inner results in CompoundResult should have a minOccurs
attribute of 0, rather than defaulting to 1. The text at paragraph 77 of the
XKMS spec part I indicates that there can be zero or more inner responses.
This makes sense because a service which does not support compound requests
will want to return an empty CompoundResult.

2. The comment field just above the CompoundResult definition mistakenly
refers to it as "CompoundResponse".

Transition history

raised on 12 May 2004 by Roland Lockhart, on behalf of XKMS
agreed on 6 Aug 2003

The changes you proposed to the specification have been accepted and the revised version of the specification may be seen at [2][3]

[2] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html

[3] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html

Acknowledgment cycle
announced by group on 6 Aug 2003

307-asanin-1: No way to specify the desired key type for LocateRequest [link to this issue]

0) As far as can see, there is no way to specify the desired key type 
(RSA/DSA/...)
in <xkms:LocateRequest/> or <xkms:ValidateRequest/>. This is not a major
problem because XKISS server may return a list of keys but I think that in
most case the desired key type is known to the client and could be used
to narrow key search on the server side (and reduce network traffic :) ).
For example, I can easily imagine that RSA and DSA keys would be stored
in different database tables. Key type may limit key search to one table 
instead of two.

Transition history

raised on 30 Apr 2004 by Aleksey Sanin, on behalf of XKMS
disagreed on 6 Aug 2003

No change was made. The ability to register or request specific types of key or key length is outside the scope of the requirements. If an application required such an ability it should define private UseKeyWith fields.

Acknowledgment cycle
announced by group on 6 Aug 2003

307-asanin-2: Use of Symmetric Keys [link to this issue]

1) It does not seem that there is a way to use symmetric keys. While public
key cryptography is became more and more afordable, there are still 
situations
when symmetric key cryptography is usefull either because of performance,
legacy or some other reasons. An use case example might be a couple of
high traffic servers when one stores some sensitive data on the client 
in an
encrypted format (say, in cookies) and another one decrypt this data. 
These two
servers may use XKISS server as a central keys storage (for example,
to provide keys rotation). Using symmetric keys might be desirable 
because of
performance reasons as well as small encrypted data size.

Transition history

raised on 30 Apr 2004 by Aleksey Sanin, on behalf of XKMS
disagreed on 6 Aug 2003

No change was made. Symmetric keys are outside the scope of the specification. While use of such keys is important the XKMS specification is predicated on the management of public keys.

Acknowledgment cycle
announced by group on 6 Aug 2003

307-asanin-3: ValidityInterval does not have optional attribute specified [link to this issue]

2) In the schema for <xkms:ValidityInreval/> element "NotBefore" and 
"NotAfter"
attributes do not have "use=\"optional\"" specified.

Transition history

raised on 30 Apr 2004 by Aleksey Sanin, on behalf of XKMS
agreed on 6 Aug 2003

Fixed - [198] line [1]

[1] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html

Acknowledgment cycle
announced by group on 6 Aug 2003

307-asanin-4: Change KeyUsage attribute maxOccurs to use unbound [link to this issue]

3) The "maxOccurs=\"3\"" for <xkms:KeyUsage/> element may prevent schema 
extension
in the future, I would suggest to change this to "maxOccurs=\"unbound\"".

Transition history

raised on 30 Apr 2004 by Aleksey Sanin, on behalf of XKMS
disagreed on 6 Aug 2003

No change was made. The element is deliberately specified so as to be restricted to cryptographic key uses and prevent extension to allow ambiguous key uses to be defined such as repudiation.

Acknowledgment cycle
announced by group on 6 Aug 2003

308-ykhan-1: Section 4.2.1 Example: Document Signature incorrect ValidateResponse [link to this issue]

I want to point out another mistake in the latest document of XKMS (18 April 2003 ) 

Section 4.2.1 Example: Document Signature 

The XKMS ValidateResponse is not correct according to the ValidateRequest  

The ValidateRequest requires KeyName element to be present in ValidateResult,  the ValidateResult has the ResultMajor = Success but only contains X509Certificate in KeyInfo, according to this example KeyName should be present in KeyInfo for ResultMajor = Success . This shows that ValidateResult is not composed successfully.

[156] Request:
<?xml version="1.0" encoding="utf-8"?>
<ValidateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Id="Ic4d10f0affff49382b021a820613fa71" 
      Service="http://test.xmltrustcenter.org/XKMS" 
      xmlns="http://www.w3.org/2002/03/xkms#">
   <RespondWith>KeyName</RespondWith>

   <QueryKeyBinding>
      <ds:KeyInfo>
         <ds:X509Data>
            <ds:X509Certificate>.....</ds:X509Certificate>
            <ds:X509Certificate>.....</ds:X509Certificate>

         </ds:X509Data>
      </ds:KeyInfo>
      <KeyUsage>Signature</KeyUsage>
      <UseKeyWith Application="urn:ietf:rfc:2633" 
            Identifier="alice@alicecorp.test"/>
   </QueryKeyBinding>

</ValidateRequest>
[157]Response:

<?xml version="1.0" encoding="utf-8"?>
<ValidateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Id="Ibc853a2455de4f7433eed5b32ece5918" 
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
      RequestId="#Ic4d10f0affff49382b021a820613fa71" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="Ie4d5784ea01e70085de088bd09b6e134">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>.....</ds:X509Certificate>

      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>

    <UseKeyWith Application="urn:ietf:rfc:2633" 
          Identifier="alice@alicecorp.test" />
    <Status StatusValue="Valid">
      <ValidReason>Signature</ValidReason>
      <ValidReason>IssuerTrust</ValidReason>
      <ValidReason>RevocationStatus</ValidReason>

      <ValidReason>ValidityInterval</ValidReason>
    </Status>
  </KeyBinding>
</ValidateResult>

Transition history

raised on 30 Apr 2004 by Yasir Kahn, on behalf of XKMS
agreed on 6 Aug 2003

Fixed - Request now has respondWith value of X509Cert so response is now consistent.

Acknowledgment cycle
announced by group on 6 Aug 2003

309-ykhan-1: Section 2.5.2: Pending Request and Response Examples incorrect [link to this issue]

In section 2.5.2 it is described:
............

Service generation of the Pending Response Message 

RequestID is set to the value of Id in the Pending request message 
Nonce is not present 
ResponseID is set to a randomly generated unique value 
............

I think in corresponding example the values are not given correctly:

2.5.3.4 Pending Request
<?xml version="1.0" encoding="utf-8"?>
<PendingRequest Id="I4294d3993de300c1ef54d49bd0903b2d" 
      Service="http://test.xmltrustcenter.org/XKMS" 
      OriginalRequestId="#I1221aaad701f0aacc65444c9bb93a7c0" 
      xmlns="http://www.w3.org/2002/03/xkms#" />
2.5.3.5 Response
<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="If91f068062d27f8f5892df0de3bb18aa" 
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
      RequestId="#Idbdf93883e29a3f1f505d6fe9d0c5979" 
      xmlns="http://www.w3.org/2002/03/xkms#" />

In 2.5.3.5 Response the value of RequestId should be "#I4294d3993de300c1ef54d49bd0903b2d" according to the specification.

Transition history

raised on 30 Apr 2004 by Yasir Kahn, on behalf of XKMS
agreed on 6 Aug 2003

Issue 1,2 Fixed

Acknowledgment cycle
announced by group on 6 Aug 2003

309-ykhan-2: Use of # Before Id Values in XKMS response [link to this issue]

I couldn't understand the logic of putting '#' before the Id values in XKMS Response.

Transition history

raised on 30 Apr 2004 by Yasir Kahn, on behalf of XKMS
Subsumed on 6 Aug 2003

Issue 3 Use of "#" This is now covered under Issue 312-dchopra-1. At present the schema uses anyURI as the type of references to the request and response IDs, this means that the reference has to be a local reference #xxxy. We propose to resolve this by either changing the type to NCName or to put in an explanation.

Acknowledgment cycle
announced by group on 6 Aug 2003

310-smysore-1: Typos [link to this issue]

http://www.w3.org/TR/xkms2/

Just before line 386,

Appendix DReferences -- TYPO; Need Space in between D & References

[CSP] TBD  -- FILL-IN HERE !!

Transition history

raised on 18 Apr 2004 by Shivaram Mysore, on behalf of XKMS
agreed on 6 Aug 2003

Fixed [2] [3]

[2] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html

[3] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html

Acknowledgment cycle
announced by group on 6 Aug 2003

310-smysore-2: Typos - Protocol Bindings Spec [link to this issue]

http://www.w3.org/TR/2003/WD-xkms2-bindings-20030418/Overview.html

Just before line 75, 

[PKIX]  TDB -- FILL-IN HERE !!

[SPKI] TDB  -- FILL-IN HERE !!

also make items in [] bold  to be consistent.

line 80 will need a hard reference soon.

just before line 84 another item [XML-ns] that needs to be in bold.

Transition history

raised on 18 Apr 2004 by Shivaram Mysore, on behalf of XKMS
disagreed on 6 Aug 2003

Fixed [2] [3]

[2] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html

[3] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-1: Use of Requester and Responder instead of Sender and Receiver [link to this issue]

Section 2, paragraph 43, two codes "Sender" and "Receiver" may make more sense if changed to "Requester" and "Responder". In any request/response protocol, where you have two messages, Receiver and Sender do not indicate the appropriate system entities. Requester and Responder make more sense. 

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
disagreed on 6 Aug 2003

The terms sender and reciever are defined in the SOAP protocol and refer to messages and not protocols.

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-2: Use Pending instead of Asynchronous [link to this issue]

Section 2.4, paragraph 51, 52, "ResponseMechanism" should have "Pending" instead of "Asynchronous".

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
agreed on 6 Aug 2003

Fixed

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-3: Section 2.4.1 - Use of Asynchronous in RespondWith [link to this issue]

3.	Section 2.4.1, "RespondWith values Represent and/or Asynchronous MAY be specified'. It should be ResponseMechanism and even then how can ResponseMechanism be set to Asynchronous in synchronous processing?

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
agreed on 6 Aug 2003

Fixed.

The requestor may offer asynchronous processing, but the responder is not obliged to honor this request.

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-4: Section 2.5 -PendingRequest [link to this issue]

4.	Section 2.5, PendingRequest is sent after the arrival of Notification. But if the requester sends PendingRequest even if Notification has not arrived, what should be the response?

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
agreed on 6 Aug 2003

If the service is not ready it simply returns pending again. This was intentional to allow for polling as opposed to notification.

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-5: Section 2.5.1 -Value of RespondWith [link to this issue]

5.	Section 2.5.1, "RespondWith value Asynchronous MUST be specified" should be changed to "ResponseMechanism value Pending MUST be specified". Same should be reflected in Section 2.5.3.1 example.

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
agreed on 6 Aug 2003

Fixed

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-6: Section 2.5.3.5 -Value of RequestID [link to this issue]

6.	Section 2.5.3.5, 'RequestID' value should be '#I4294d3993de300c1ef54d49bd0903b2d".

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
agreed on 6 Aug 2003

Fixed

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-7: Difference between Asynchronous processing and 2 phase protocol [link to this issue]

7.	Section 2.6, in the differences between asynchronous processing and two phase request protocol, it is not pointed out clearly that while asynchronous processing is mandatory (once it is specified by request RespondWith) whereas two phase request protocol usage is the discretion of responder.

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
agreed on 6 Aug 2003

No, asynchronous processing is always an option. Fixed the text to make this clearer

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-8: Is nonce required [link to this issue]

8.	Section 2.6.2, document specifies one method of nonce construction. Is it mandatory to use this method? Paragraph 68 does not suggest that.

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
agreed on 6 Aug 2003

It is open to implementors, the text has been fixed to make this clear.

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-9: Who can handle CompoundRequests? [link to this issue]

9.	Section 2.8, paragraph 76, "Web Service" mention is unclear here. Till now, all the services are XKMS services. Does it mean that only web services can handle compound requests?

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
agreed on 6 Aug 2003

Fixed

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-10: Section 3.2.4 [link to this issue]

10.	Section 3.2.4, for Mechanism attribute, "A URI that specifies the protocol by which the notification is made". <PendingNotification> is a part of <RequestAbstractType> so it is going to be used by requester. And requester is not using Mechanism attribute, it is merely specifying it. In my opinion, "A URI that specifies the protocol by which the notification CAN BE made" seems more appropriate.

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
agreed on 6 Aug 2003

Its a MAY, Fixed

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-11: Fix types for OriginalRequestID, RespondID, RequestID [link to this issue]

11.	OriginalRequestId (RequestAbstractType), RespondID (PendingRequest) , RequestId (ResultType) should be of type "xsd:NCName" as they are referring to "xsd:ID" type elements in other XML docs.

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
Subsumed on 6 Aug 2003

This has been deferred to issue 312-ykahan-2 for further action. http://lists.w3.org/Archives/Public/www-xkms/2003Aug/0023.html

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-12: Authentication [link to this issue]

12.	Section 3.3.2, paragraph 124, "The corresponding request was not authenticated, or..." does it mean that ResultMajor.ResultMinor is Sender.NoAuthentication? If yes, then this probably is more concrete wording.

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
disagreed on 6 Aug 2003

No. The constraint is correctly on the request, if there is no signature on the request then there is no way to link it in the response. This is not the same as no authentication which indicates a violation of the service authentication policy. The lack of the signature in this case is simply a logic error since the requestor is asking the service to return a data item that was not provided.

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-13: Add details to CompoundRequest as per schema [link to this issue]

13.	Section 3.4.1, CompoundRequest can have multiple requests of the same type. Although this is clear from the schema definition, it would be better if some text can be provided to indicate that. Besides that there is no clear reasoning given for that.

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
agreed on 6 Aug 2003

Fixed

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-14: UseKeyWith Identifiers [link to this issue]

14.	Section 5.1.3, paragraph 178. UseKeyWith specifies subject identifier and application identifier but the corresponding attributes (Identifier and Application) do not seem consistent. Probably attributes like Subject and Application; or SubjectIdentifier and ApplicationIdentifier seem more appropriate.

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
disagreed on 6 Aug 2003

This would break existing applications without providing significant value. No Change

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-15: Bindings Doc: Section 3.1 [link to this issue]

1.	Section 3.1, can we have some other XML elements besides XKMS content inside Body element? Document does not say anything about that.

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
disagreed on 6 Aug 2003

This is a SOAP issue

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-16: Bindings Doc: Soap fault error codes and use of Requester and Responder [link to this issue]

2.	In the SOAP Faults section, error codes are "env:Receiver" and "env:Sender". In any request/response protocol, where you have two messages, Receiver and Sender do not indicate the appropriate system entities. Requester and Responder make more sense. So probably "env:Requester" and "env:Responder" seem little bit better.

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
disagreed on 6 Aug 2003

This is the SOAP spec.

Acknowledgment cycle
announced by group on 6 Aug 2003

311-dchopra-17: Bindings Doc: Where is the 3rd security binding? [link to this issue]

3.	Section 4, "This specification describes three principal security bindings...". I can see two, Payload Authentication Binding and SSL/TLS Security Binding. Where is the third one?

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
agreed on 6 Aug 2003

Fixed

Acknowledgment cycle
announced by group on 6 Aug 2003

312-dchopra-1: Fix types for OriginalRequestID, RespondID, RequestID [link to this issue]

11.	OriginalRequestId (RequestAbstractType), RespondID (PendingRequest) , RequestId (ResultType) should be of type "xsd:NCName" as they are referring to "xsd:ID" type elements in other XML docs.

Transition history

raised on 20 May 2004 by Dipak Chopra, on behalf of XKMS
agreed on 6 Aug 2003

I took a look at this. It seems to make sense to me. A NCName production is lexicaly the 'local' part of a URI - i.e. after the # mark.

This seems better than anyURI, it would mean that references to requests and responses would no longer require the # mark.

On the other hand this would break all the examples (not a real issue) and any code. On the other hand the changes to the existing code would be pretty simple.

JK: Although there was no announcement on the mailing list, the editor applied the proposed change in the xkms xsd schema and the examples were cleaned up. See also issue312-ykahan-2

Acknowledgment cycle
announced by group on 6 Aug 2003

312-ykhan-2: Use of # before Id Values in XKMS response [link to this issue]

I couldn't understand the logic of putting '#' before the Id values in XKMS Response.

Transition history

raised on 30 Apr 2004 by Yasir Kahn, on behalf of XKMS
agreed on 6 Aug 2003

JK: XKMS uses the the ID value to identify each request and response. Apparently the spec. was not consistent enough in the use of "#" before the ID values when quoting a previous message, e.g., the RequestID in a Response message, as it sometimes appeared and sometimes didn't. Following a related comment, the XKMS schema was changed and the use of the "#" become unnecessary. All the examples were cleaned up in the editor's draft, although there was no direct answer sent at the time. A follow-up message to the issuers of this comment did not occur in further feedback.

Acknowledgment cycle
announced by group on 6 Aug 2003

Maintained by XKMS Working Group.

Last update: $Date: 2004/03/12 16:05:53 $


This page was generated as part of the Extensible Issue Tracking System (ExIT)