Re: FW: XKMS fixes

Please nopte that that issues list is referred to as "Last Call Issues 
List" [2] from the Spec item on our main page[1]

[1]  http://www.w3.org/2001/XKMS
[2]  http://www.w3.org/2001/XKMS/Drafts/xkms-spec-lastcall-issues.html

/Shivaram

Hallam-Baker, Phillip wrote:
> 
> 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??
>  
>  
>  
>  
>  
>  
>  
>  
>  

-- 
_____________________________________________________________________
Shivaram H. Mysore <shivaram.mysore@sun.com>

Software Engineer                   Co-Chair, W3C's XKMS WG
Java Card Engineering               http://www.w3.org/2001/XKMS
JavaSoft, Sun Microsystems Inc.

Direct: (408)276-7524
Fax:    (408)276-7674

http://java.sun.com/people/shivaram  (Internal: http://mysore.sfbay/)
_____________________________________________________________________

Received on Thursday, 10 July 2003 17:42:47 UTC