FW: XKMS fixes

More to follow soon...
 
These are the ones itemized in the issues list, excluding a couple of
involved edits.

 Issue 301 - Fixed

XKMS 2.0 implementations MUST support the use of SOAP 1.2. For near term
compatibility with existing tools and infrastructure, SOAP 1.1 MAY be used

[Examples fixed]

Issue 302 - To be addressed in DSS spec

The issue concerns the use of delgated signatures. Is this a different
cryptographic key usage? I don't see this as being the case, the key storage
is irrelevant to the external applications in most cases. If the key storage
is relevant then it would seem to be a protocol issue.

This would appear to suggest that the correct approach is to address this
issue through the UseKeyWith mechanism as suggested. This leaves open the
issue of where the corresponding URI is defined. In this case it would
appear that this is an issue for the DSS protocol WG since it is not at the
appropriate standards status level for a normative reverence from XKMS.

Issue 303 - See separate note

A lot of the issues Denis raises are ones of architectural principles rather
than implementation. Others point out areas where the spec can be usefully
improved. So first we have to process these on the issues list.

Issue 304 - 5 issues are raised

1. Section 2.6:  Two Phase Request Protocol.

Carlisle raises an important issue, one that at present cannot be fully
answered, clearly WS-Policy or some similar mechanism is required if the
client is going to know in advance what options the service requires. The
situation can however be improved by adding an appropriate error code. Note
that this would not be a 'recoverable' error in that the client would not be
expected to retry offering represent, it is simply a means of supplying the
additional info to alow the cause to be analysed.

This seems to address the confusion indicated in the second part of the
note, the error code had not been catalogued correctly and was in any case
confusing, it is a sender error.


RepresentRequired	 Sender	 The responder requires that the sender
offer the represent protocol option in order to process the request.	

2. Must Represent missing - Fixed See above
 
3. Fixed - good point
 
 If the response is signed this provides a cryptographic linkage between the
request and the response.
 
4. Defered - will come to later
 
5. Fixed
 
5a. Not changed
 
The key derivation algorithm is carried over from v1.0 of the spec. We can
start a separate discussion on the merits of making a change.
 
305 Editorial - deferred till after tea.
 
306 Fixed
 
The two schema fixes have been made.
 
307 Four issues raised:
 
1. Discuss - Should there be a way to request a DSA key or an RSA key?
 
This is a good point. It could be addressed through UseKeyWith, it is
essentially a constraint on the algorithm... 
 
2. Not Changed
 
I agree that symmetric keys are an important issue. However I do not
consider them to be a sub-case of public key, they are a completely
different category as far as I am concerned. I don't see how a public key
information system would work for them.
 
3. Fixed in part.
 
The validity interval issue was a bug.
 
The bound was quite deliberate to prevent anyone defining a
'non-repudiation' usage. Should we revise this decision?
 
4. Not an editorial issue
 
308, 309 Deferred - to coding day 
 
Also have to make sure that all the QNames referenced are actually defined
in the spec tables. In particular Multiple.
 
310 Editorial
 
These are fixed in my copy of 31st March but not apparently in the 'last
call' version....
 
Agghghj!
 
Anyone know where I can get a HTML document differencer program??