301
|
W3C
XML Protocol
|
Editorial Fix for SOAP 1.2 Usage; Editorial
fixes required for Part 2 of the spec.
Fixes Para 42 & 46-47
|
Closed
|
302
|
Oasis
DSS TC
|
Support for Delegated Signature in KeyUsage
Issue
should be addressed in DSS specification
|
Closed
|
303
|
Denis
Pinkas - IETF/PKIX
|
Need to clarify what is an issue and what is not
- see email
A number of
changes to the text in response to certain comments, other comments
noted without a change being made.
|
Closed
|
304
|
Carlie
Adams
|
- 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.
- Section 3.3.2: Element . 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.
- Section 6.1.1: Example: Registration of Client-Generated
Key Pair. In the 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 elements in ? 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?
- 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?]
|
Closed
|
305
|
Joseph
Reagle
|
Document doesn't flow as smoothly as it might:
- Section 1 says there are two "service specifications" but
doesn't say where they are more fully described or specified. Forward
references?
- The sections in section 1.7 do not correspond to the
sections of the table of contents.
- 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.
- Generally, I don't distinguish between a "message format"
and a "message syntax." What do these section do differently?
|
Closed
|
306
|
Roland
Lockhart
|
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
:
- 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.
- The comment field just above the CompoundResult definition
mistakenly refers to it as "CompoundResponse".
Schema Fixed
|
Closed
|
307
|
Aleksey
Sanin
|
- 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.
- 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.
- In the schema for <xkms:ValidityInreval/> element
"NotBefore" and "NotAfter" attributes do not have "use=\"optional\""
specified. 3) The "maxOccurs=\"3\"" for <xkms:KeyUsage/> element
may prevent schema extension in the future, I would suggest to change
this to "maxOccurs=\"unbound\"".
- Interop Test suite available ??
|
Closed
|
308
|
Yasir
Khan
|
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.
Fixed
|
Closed
|
309
|
Yasir
Khan
|
- 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
..........
- Corresponding example the values are not given correctly:
In 2.5.3.5 Response the value of RequestId should be
"#I4294d3993de300c1ef54d49bd0903b2d" according to the specification.
- Clarify use of "#" before the Id values in XKMS Response
Fixed -
Issue 3 continued under Issue 312
|
Closed
|
310
|
Shivaram
Mysore
|
Editorial:
- Just before line 386, Appendix DReferences -- TYPO; Need
Space in between D & References
- [CSP] TBD -- FILL-IN HERE !!
Protocol Binding Spec (Part 2):
- 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.
Fixed
|
Closed
|
311 |
Dipak
Chopra |
Main Document
- 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.
- Section 2.4, paragraph 51, 52,
"ResponseMechanism" should have "Pending" instead of "Asynchronous".
- 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?
- 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?
- 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.
- Section 2.5.3.5, 'RequestID' value should
be '#I4294d3993de300c1ef54d49bd0903b2d".
- 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.
- Section 2.6.2, document specifies one
method of nonce construction. Is it mandatory to use this method?
Paragraph 68 does not suggest that.
- 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?
- 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.
- 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.
- 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.
- 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.
- 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.
Bindings Document
- Section 3.1, can we have some other XML
elements besides XKMS content inside Body element? Document does not say
anything about that.
- 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.
- 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?
Fixed - New issue 312 created
on subject of open item #11.
|
Closed |
312 |
Dipak
Chopra &
Yasir
Khan
|
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.
Clarify use of "#" before the Id values in XKMS Response
|
Closed,
Closed |