Re: xkms

Some comments on:

XKMS-20020305/Overview.html from
http://lists.w3.org/Archives/Public/www-xkms/2002Mar/0080.html

> Abstract
> Executive Summary
>                                  Introduction

Since these all contain the same paragraph, I would remove the Executive 
Summary and integrate its paragraphs into the Introduction.

> Definition of Terms
>      Service
>          An application that provides computational or informational
>      resources on request. A service may be provided by several physical
>      servers operating as a unit.

I'm more confused by this second sentence than helped. Perhaps it should be 
removed.

> Namepaces
>    xkms    XKMS               http://www.w3.org/2002/03/xkms#

Note, the namespace in the published version does *not* include the hash on 
the end since I couldn't find any "subtypes" at the time of its 
publication. But if we do want to create more such "sub" namespaces, we can 
create a new namespace:
  http://www.w3.org/2002/04/xkms#

> Key Information Service Specification Overview (Non-Normative)
>
>    X-KISS allows a client to delegate part or all of the tasks required
>    to process XML Signature <ds:KeyInfo> elements to a Trust service.

Is this true? An XKMS service will signature validate a signature for you? 
Editorial: we should continue to strip out CSS on lots of specific elements 
(like <div style="margin-left: 2em">) and bracketing xml tokens in <tt/>.

>    For example Alice signs a document and sends it to Bob with a
>    <ds:KeyInfo> element that specifies only the signing Key Data.

why  caps on Key Data ?

>              Figure 3: Locate Service Provides Name Resolution

This is something I'm ignorant on, but I would've presume that server - A 
would've returned info to "Trust Service" which would've returned the data 
to the client. How is a client to know that unsolicited responses from 
servers it didn't contact correspond to its request? It then needs to keep 
a list of other servers to trust? But I though the point is to simplify 
this? Shouldn't I just deal with the person I trust, and if he needs to 
defer, that information flows through him?

Also, I prefer we speak of "XKMS service" instead of "trust service" since 
not all services have a lot to do with "trust" (e.g., locate), and its an 
ambiguous term. For example, this diagram should have XKMS Service A and B.


>    <Locate>
>       <Query>
>          <ds:KeyInfo>
>             <ds:RetrievalMethod
>               URI="http://www.PKeyDir.test/Certificates/01293122"
>               Type="[30]http://www.w3.org/2000/09/xmldsig#X509Data"/>
>          </ds:KeyInfo>

In time, I expect we'll want to have real XML with the proper namespace 
declarations that people could plug and play with.

Also, as stated elsewhere, I don't see why we need different Locate and 
Validate requests.

>       <Respond>
>          <string>KeyName</string>
>          <string>KeyValue</string>
>       </Respond>

Again, these are not  strings. If we want to specify the 
Respond/sql:Select, then we should give a proper prototype. We should also 
specify how the prototype is satisfied: must one return all elements: if 
not match does one return an empty element or not include the element at 
all? If one wants a ds:KeyInfo with the two children elements then one 
should ask for:

<Respond>
  <ds:KeyInfo>
   <ds:KeyName/>
   <ds:KeyValue/>
  <ds:KeyInfo>
</Respond>


>    ValidityInterval
>    The request was made within the validity interval of the assertion
>    The request was made at a time when the certificate chain was valid

I'm still confused about this. What does this mean if the meaning if 
invalid. Needs further definition.

>    TransactionID
>           The transaction identifier.

??

>    Answer
>    A sequence of strings that contain <ds:Keyinfo> elements that provide
>    the information specified by the Respond attribute, for the public key
>    identified by the Query element.

No not strings, namespace qualified XML element types.

>    The response message returns a ResultCode depending on the success of
>    the Locate operation as follows:

These "codes" are the same for a Validate versus Locate (another reason to 
think that this bit is associated  with a generic Request (don't need both 
of those queries.)

>                                  ResultCode
>    NoMatch

The relationship between AssertionStatus, Result and Reason need to be 
carefully (if not formally) specified -- if we cleanly separate the 
"protocol request" from the data requested I think this will be easier. 
This goes back to my question on how much data must be returned to be 
considered valid.  For instance, 

1. if an XKMS client asks for A,B,C, and 
2. The service has A,B and knows they are bound, but is less sure C. Does 
the service return
a. A,B with AssertionStatus=Valid, Result=Success, Reason=Incomplete
b. A,B with AssertionStatus=Valid, Result=Incomplete, Reason=Incomplete
c. A,B,C with AssertionStatus=Indeterminate, Result=Success, Reason=Success

I'd presume option b, but then is one supposed to read that as the 
AssertionStatus is Valid because (the Reason) is the data is Incomplete? 
Yikes!


>    <ValidityInterval>
>           The time interval in which the key binding relationship is
>           asserted


>    TBS precise meanings wrt Validity Interval

Right, which of the many "valid" its qualifies and exactly which data and 
relationships.

>    Protocol  Application URI Subject
>    S/MIME                    mailto:
>    SSL/HTTPS                 http://
>    IPSEC

What about https:// ??

>                                  ResultCode
>    NoMatch
>    No elements
>    The validate operation succeeded but returned no matches.

What does this mean?! How can it not find any information that is "bound" 
but its stilll "valid"?

>                   Key Registration Service Protocol Overview
>    On receipt of a registration request, the registration service
>    verifies the authentication and POP information provided (if any). 

What is POP?

>    <Register>
>       <Prototype Id="keybinding">

It's odd that we speak of prototypes elsewhere, and actually use the syntax 
here. We should rationalize the syntax on that front.

>    The service accepts the registration and returns the following
>    response:
>          <ds:KeyInfo>
>             <ds:RetrievalMethod
>                  URI="http://www.PKeyDir.test/Certificates/01293122"
>                  Type="[38]http://www.w3.org/2000/09/xmldsig#X509Data"/>
>             <ds:KeyValue>
>                <ds:RSAKeyValue>
>    <ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7Ef
>                   dxSXAidruAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw</ds:Modulus>
>                   <ds:Exponent>AQAB</ds:Exponent>
>                </ds:RSAKeyValue>
>             </ds:KeyValue>
>             <ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName>
>          </ds:KeyInfo>

Note, the order of the ds:RetrievalMethod, ds:RSAKeyValue, ds:KeyName is 
not the same as in the Register message. Is order not important? Or does 
its unspecified behaviour satisfy the schema definition?


[Runs out of time ....]


-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Friday, 22 March 2002 14:40:22 UTC