Question/Comment

Hello All,

I've been reading through XKMS 2.0 and had a simple question about the
schema definition for the Request Message for X-KISS (Tier 1 Locate
Service).

The schema definition is defined as such:

<element name="LocateRequest" type="xkms:LocateRequestType"/>
<complexType name="LocateRequestType">
    <complexContent>
        <extension base="xkms:RequestAbstractType">
            <sequence>
                <element ref="xkms:TransactionID" minOccurs="0"/>
                <element ref="xkms:KeyInfoQuery"/>
            </sequence>
        </extension>
    </complexContent>
</complexType>
<element name="TransactionID" type="string"/>
<element name="KeyInfoQuery" type="ds:KeyInfoType"/>


Yet the Locate example earlier in the document formats the Locate message
like this:

<Locate>
   <Query>
      <ds:KeyInfo>
         <ds:RetrievalMethod
           URI="http://www.PKeyDir.test/Certificates/01293122"
           Type="http://www.w3.org/2000/09/xmldsig#X509Data"/>
      </ds:KeyInfo>
   </Query>
   <Respond>
      <string>KeyName</string>
      <string>KeyValue</string>
   </Respond>
</Locate>


Shouldn't the example use <LocateRequest> as the parent element name and
<KeyInfoQuery> as the Query element instead of <Locate> and <Query>?

I apologize if this is a trivial question, but this concerns me a bit
because the examples presented in the earlier XKMS also used <Locate> and
<Query> which doesn't seem to match the schema def. Perhaps I am reading it
wrong?

Thanks,

Blake Dournaee
Toolkit Applications Engineer
RSA Security
 
"The only thing I know is that I know nothing" - Socrates
 
 


-----Original Message-----
From: Frederick Hirsch [mailto:hirsch@zolera.com]
Sent: Wednesday, November 28, 2001 12:04 PM
To: www-xkms-ws
Subject: XKMS 2.0 - editorial comments


I have some editorial comments that may be premature, but thought I'd share
them anyway.

Should confidentiality be mentioned in the Validity of Service response
section? Should this section be common for both KISS and KRS? (there are
diffrerences, regarding correspondence and possession, but having a common
XKMS response would be useful)

I suggest rewording the first sentence of Validity of Service section:
"Clients SHOULD ensure the integrity of the response from the service to a
Locate or Validate operation, meaning that the foloowing criteria are met:"

In the Respond identifiers table, indicate that * means one or more elements
might be returned.

A reference to the definition of the OCSP token that validates an X509v3
certificate would be useful.

In the  Element reason - aspect table the description of ValidityInterval is
in terms of now, at the time of the request. We should note that to
determine if KeyInfo was valid when a signature was created is out of scope,
since that would require passing signature properties as well as KeyInfo to
a service, assuming signature properties included an appropriate timestamp.

I'd recommend making the SOAP bindings a separate document from the core
XKMS spec.

we might want to clarify that for the Passphrase element the MAC is applied
once when proving knowledge to avoid passing phrase in clear, and twice at
registration to avoid passing proof in the clear at registration.

Key Recovery: the draft should state that key revovery is only useful for
encryption since the server is required to revoke a recovered signing key.

In XKRS registration  We might want to move the paragraph beginnning with
"For clarity" before the example.

Does the phrase "limited use" need definition in the term "limited use
shared secret"?

Revised wording for Replay Attacks, 2nd paragraph 2nd line:
"For example, if  a generic mechaims is built into the object exchange
protocol, then it MAY be used."

Rewording of nonce bullet
"A nonce, that is a piece of random data that was included in the request

Typos:

"XML-SIGelements" in Executive Summary should be 2 words
"Namepaces" missing s, heading after Definitions of Terms section
"XMKMS" typo in Namespaces section
The TBS for the xkms namespace can be the namespace in the XML Schema below
Hellman is misspelled in Diffie-Hellman at the end of KRSS Overview
"revoked" instead of "registered" at end of paragraph in Prototype element
definition for Revoke Request Message
"recovered" instead of "registered" at end of paragraph in Prototype element
definition for Recover Request Message

Figures
Figure 2 might want to match the url retrieved with the example text
Figure 3 might show parsing of certificate in middle (maybe)


---
Frederick Hirsch
Zolera Systems, http://www.zolera.com/
Information Integrity, XML Security

Received on Thursday, 29 November 2001 16:20:39 UTC