Re: Changelog #2

The top 3 remaining issues are :

1. More connective stuff is needed to explain ID model for KeyBinding
(see @1(2.29,3.31, 3.33, 3.38))
   For example,  I am still unclear if one can use ID as a stable
identifier for a distinct persistent KeyBinding object or is it just a
transient message-scoped value used just to reference XML element from a
signature block of the same protocol message. I am afraid that different
implementations may end up assuming different interpretations which will
impede interoperability.

2. Define matching rules for <QueryKeyBinding> when multiple
<UseKeyWith> or <PolicyIdentifier>or <KeyUsage> are used (see
@1(2.20,2.30))

3. Address a potential request substitution vulnerability stemming from
the fact that XKRSS request type is not part of the signature scope of
KeyBindingAuthentication which allows one to transform certain forms of
ReissueRequest, RevokeRequest and RecoverRequest into each other (see
@1(3.35))

References
@1= http://lists.w3.org/Archives/Public/www-xkms/2002Nov/0037.html

Some other item-specific comments are interspersed below.

"Hallam-Baker, Phillip" wrote:

> 1.2 Deferred, should put detailed error into the SOAP binding return.
>

Are we envisioning support for bindings other than SOAP in the future ?
Is it convenient to get reason code from the payload and error details
from the envelope ?


> 1.9, 1.10 Added in some clarifying text:The request resulted in the
> number of responses that exceeded either  the ResponseLimit value
> specified in the request or some other limit determined by the
> service. The service MAY either return a subset of the possible
> responses or none at all.

I think for 1.10 it is still somewhat unclear on when the implementation
is supposed to use Success.Incomplete vs Success.TooManyResponses

>
> 1.23 Why insist on a single blob? I don't see any advantage, I see
> plenty of inconvenience.

This is certainly too insignificant to spend any more energy on. Given
that the client constructs it and the server blindly returns it, I was
just curious about the scenario where sequence of opaque values is more
convenient than a single opaque value.

>
> 2.25 No change
>
> Explanatory material is usually bad ju-ju in specifications. The
> reason why locate is required is that there are highly complex PKIs
> such as the FBCA and its international counterparts which are designed
> to have thousands of peer CAs operating. There is simply no way that
> end-entity applications can be expected to navitgate this soup in a
> meaningful or useful way because of the sheer volume of information
> required.
>
> A locate service can simply maintain a database of every CA cert and
> every cross cert and the paths between them the same way that MAPQuest
> maintains a database of highways.
>
> The people deploying these apps often want to apply the end to end
> argument and so they want to do delegated path discovery but implement
> path chain verification localy. The path math stuff is tedious but
> relatively straightforward.

I am still a little puzzled by the example [123-125]. If a client has
access to both Locate and Validate services, what would be the
motivation for "first querying the un-trusted Locate service and then
forward the information received to a Validate service to establish its
trustworthiness" rather than directly using only the Validate service to
do both locate and validate in a single request/response.

> 3.13 No Change
> Can raise to an issue if someone wants to argue the case here.
> Detailed reasons can be reported through the SOAP mechanisms.

See comment for 1.2 above

> 3.37 Pending
> At the moment HMAC-SHA1 is hard coded. Issue do we want to have
> algorthm changability? I don't want to do negotiation in the XKMS
> protocol but we could define a UDDI/WSDL parameter to allow this to be
> configured as desired.
>
Perhaps we should add an attribute for MAC algorithm used to
RevocationCodeIdentifier and RevocationCode and have a list of MAC
algorithms a server MUST support. Obviously mismatch of MAC algorithm
between the original Register and subsequent Revoke request will result
in an error.
--
Slava Galperin
mailto:slava.galperin@sun.com

My contribution was: to stay out of the way.
 (from the movie "The Million Dollar Hotel")