Changelog #2

Response to Slava Galperin's comments 


1.1 Added Receiver.NotImplemented as error result
 
1.2 Deferred, should put detailed error into the SOAP binding return.
 
1.5 Added the following clarification
 
In the case that an XKMS service is providing an interface to an
underlying PKI, clients MUST NOT rely on the service choosing key
binding identifiers that are either the same as or bear a systematic
relationship to the serial numbers or other identifiers of the
corresponding credentials in the underlying PKI.
 
1.6 Made the following change:
 
SSL/HTTPS	 urn:ietf:rfc:2817	 DNS address of http server
DNS Address	
SSL/SMTP	 urn:ietf:rfc:2487	 DNS address of mail server
DNS Address	
 
It is still important to differentiate between MAIL and HTTP since a
server could have separate certificates for service on the different
ports.
 
1.7, 1.8 done
 
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.
 
1.13 Deferred to list discussion
 
1.14 Deferred to discussion
Actually there is but it is outside our scope, you would simply use the
OID:20.3045.2.4 URN scheme...
 
1.16 Done
 
1.17 Actually a comma was missing...
 
Unless an XKMS service which provides key information about keys bound
to email addresses in the domain cryptographer.test is known a priori,
some means of locating the correct XKMS service is required.
 
1.18 done
 
1.19 Deferred
 
1.20 done
 
1.23 Why insist on a single blob? I don't see any advantage, I see
plenty of inconvenience.
 
1.24 done
 
 
2.1 If the assertions all hold good for either key I see no problem.
Introducing a restriction is not feasible since it would involve
changing ds:keyinfo.
 
2.2 See list discussion on policy identifiers. I don't think we really
want to go there, I tend not to be too concerend about policy
identifiers because I don't think that any sane user application can
make very much use of them. Any policy mapping stuff has to be done in
the service and concealled from the client as much as possible.
 
2.4 The behavior of XKMS on top of X.509 is outside the scope of the
spec. The service should do what is appropriate to insulate the
*application* from the gory details of PKI, so doing the right thing
might be different for S/MIME or SSL. If the question is 'give me a key
to talk S/MIME to Alice NOW the answer is obviously one key, if the
question is what WAS the key for Alice 3 years ago then the best answer
is probably both.
 
2.20 Deferr to list discussion.
 
2.21, 2.22 Added in an explanation
 
The application then verifies that the certificate obtained meets its
trust criteria by standard certificate validation to a trusted root.
 
2.23 done, actually the validity interval was not relevant so deleted.
 
2.24 clarified as follows:
 
The Locate and Validate operations are both used to obtain information
about a public key from an XKMS Service. Locate and Validate services
are both expected to attempt to provide correct information to the
requestor. The Locate and Validate services differ in the extent to
which the service vouches for the trustworthiness the information
returned. A Location service SHOULD attempt to provide only information
which is trustworthy to the best of its knowledge. A Validation service
undertakes to only return information which has been positively
validated by the XKMS Service as meeting its validation criteria.

Information obtained from a Locate service SHOULD NOT be considered
trustworthy unless it is verified. Verification may be achieved by
forwarding the data to a Validate service or by performing the necessary
trust path verification locally.

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.

2.26 No change

Wel you would not normally. That is why the spec talks about discovering
a locate service via DNS rather than a validate. The idea is that the
raw data obtained from the DNS via locate is then post validated.

However there is a twist here, if you have deployed DNSSEC it is quite
reasonable to believe that there might be a situation where you would
locate validate services in that way. Also you could perform a
credential request on the validate service and build a trust path that
way.

2.27 Will edit the code later

2.28 OK, put in a conditional clause:

A Key Binding asserts a binding between data elements that relate to a
public key including the <ds:KeyName>, <ds:KeyID>, <ds:KeyValue> and
<ds:X509Data> components contained in a <KeyInfo> element. Furthermore,
the Service represents to the client accessing the service and in the
absence of specific undertakings to the contrary to that client alone
that the binding between the data elements is valid under whatever trust
policy the service offers to that client.

Point is that the XKMS service may not want the response to be
transferrable. For example if someone asks me in a bar 'is Bob good to
borrow $50' I might well answer yes the first twenty times or so and
then start to wonder.

2.29 No change

The specification takes no position here. This is something that is very
likely to be profiled in different ways, I can think of cases where I
would want each of the behaviors listed.

2.30 Deferred, policy discussion.

2.31 Done (think this was a hangover from the one keybinding days)

2.32 Done

2.33 Done

2.34 Done

2.35 Removed:

The Validate service allows the client to query the binding between a
<ds:Keyinfo> element and other data such as an identifier. The client
supplies a prototype for the key binding requested. The prototype may
specify either a <ds:Keyinfo> element or one or more <UseKeyWith>
elements or  both. The server returns one or more <KeyBinding> elements
that meet the criteria specified in the request.

2.36 Done
 
3.1 No change
 
What information is missing? The preceeding descriptive section
describes how the operation is used.Don
 
3.2 No Change
 
The Appendix gives a blow by blow account of how to form the
authentication string including the intermediate results from the
calculation steps
 
3.3 No Change
 
I don't really want to do duplicate examples unless there is a major
distinction. A non X.509 example would simply omit the X.509 specific
information.
 
3.4 Done
 
3.5 No change
 
Because 1) we don't want to force clients to have to support enveloped
signature processing which is really icky. and 2) there might be an
intermediarry involved that may make certain changes en route to other
parts of the message.
 
3.6 Defer to list discussion of the secrecy of the symmetric key.
 
3.9 No change
 
The specifics of individual deployments are out of scope. An RA is very
likely to put some wrapper arround the authentication. I don't think we
need to worry about interop between the RA and issuing authority as our
concern since there is likely to be a lot of out of issues to be
profiled there.
 
3.11 No Change
 
See discussions on list passim, essentially this type of stuff is
possible through UseKeyWith abuse. There is general skepticism on the
value of X.509 data elements since once you start down that slope the
ability to parse ASN.1 becomes only one of your many woes.
 
3.12 No Change
 
Basically you can specify the X.509 DN via UseKeyWith. That seems the
right place to me since using keyname would imply some sort of priv'd
position for X.509
 
We do some stuff with KeyName that is highly proprietary. Basically
using KeyName to do anything but provide a label for easy key retrieval
is going to be problematic.
 
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. 
 
3.14 No change
 
see earlier comment, no the client should not rely on this
 
3.15  No Change 
 
can discuss on list if we want to go for futher linkage to the X.509
world. The discussion on the policy topic suggests to me that this is
somewhere the group is not keen to go.
 
3.17 Don't understand the question.
 
3.18 Added
 
3.19 No, simply reissue the pending request until it is satified.
 
Need to clarify the connection here - see Joseph's comment
 
3.20 Done
 
3.30 No change
 
The service has the right to decide on any aspect of the issued key
binding. In particular the validity interval is typically set by the
registration service policy and the service is not going to take any
notice of any input from the client.
 
3.31 No
 
3.32 No, only the proof of possession is self signed. In the example the
authentication is a shared secret so no key info is required, the
signing mechanism is given by context.
 
Issue: do we need to specify the keyinfo block a little more clearly?
Like define a dummy KeyID for a shared secret?
 
3.33 No change
 
Key binding IDs may or may not be systematic. 
 
Issue: Do we need a bit of connective stuff here to explain the ID model
beyond that we have already?
 
3.34 No change
 
It provides the motivation for the translation to lower case and
elimination of spaces and hyphens.
 
3.35 No change
 
See earlier comment 3.9
 
3.36 Pending
 
need to rev all the example code
 
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.
 
3.38 Pending
 
Issue: can we realisticly specify anything usefull here? 
 
3.39 No change
 
It is policy dependent. In many cases the reissue is done to simply
download the updated certificate. Any other requirements need to be
specified via WSDL/UDDI or whatever