RE: xkms 2.0 issues

This message is in reply to issue #307 [1] that you raised during the XKMS
WG Last Call request on behalf of the XML Protocol WG.

The changes you proposed to the specification have been acted on as follows
and the revised version of the specification may be seen at [2]

1)	No change was made
	The ability to register or request specific types of key or key
length is outside the scope of the requirements. If an application required
such an ability it should define private UseKeyWith fields.

2)	No change was made
	Symmetric keys are outside the scope of the specification. While use
of such keys is important the XKMS specification is predicated on the
management of public keys.

3a)	Fixed - [198] 

3b)	No change was made
	The element is deliberately specified so as to be restricted to
cryptographic key uses and prevent extension to allow ambiguous key uses to
be defined such as repudiation.

4)	Is not a last call issue
	Entrust have announced an interop test service, others are likely to
announce services once the last call changes are complete.

At this point the work group believes all concerns raised in issue #307 have
been addressed and that the entire issue is closed, unless we hear
otherwise. (see [3] for additional resolutions)

The XKMS WG would like to thank you for reviewing and commenting on the
draft XKMS specification.

Regards, 
Phillip Hallam-Baker on behalf of the XKMS WG
VeriSign Inc.

[1] http://lists.w3.org/Archives/Public/www-xkms/2003May/0001.html
[2] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html
    http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html
[3] http://lists.w3.org/Archives/Public/www-xkms/2003Aug/0005.html



> -----Original Message-----
> From: Aleksey Sanin [mailto:aleksey@aleksey.com]
> Sent: Thursday, May 01, 2003 1:03 AM
> To: www-xkms@w3.org
> Subject: xkms 2.0 issues
> 
> 
> 
> Hi, All!
> 
> I am preparing to do the XKMS 2 implementation in XML Security Library
> (http://www.aleksey.com/xmlsec) and after reading the spec I 
> found some
> issues:
> 
> 0) As far as can see, there is no way to specify the desired key type 
> (RSA/DSA/...)
> in <xkms:LocateRequest/> or <xkms:ValidateRequest/>. This is 
> not a major
> problem because XKISS server may return a list of keys but I 
> think that in
> most case the desired key type is known to the client and 
> could be used
> to narrow key search on the server side (and reduce network 
> traffic :) ).
> For example, I can easily imagine that RSA and DSA keys would 
> be stored
> in different database tables. Key type may limit key search 
> to one table 
> instead of two.
> 
> 1) It does not seem that there is a way to use symmetric 
> keys. While public
> key cryptography is became more and more afordable, there are still 
> situations
> when symmetric key cryptography is usefull either because of 
> performance,
> legacy or some other reasons. An use case example might be a couple of
> high traffic servers when one stores some sensitive data on 
> the client 
> in an
> encrypted format (say, in cookies) and another one decrypt this data. 
> These two
> servers may use XKISS server as a central keys storage (for example,
> to provide keys rotation). Using symmetric keys might be desirable 
> because of
> performance reasons as well as small encrypted data size.
> 
> 2) In the schema for <xkms:ValidityInreval/> element "NotBefore" and 
> "NotAfter"
> attributes do not have "use=\"optional\"" specified.
> 
> 3) The "maxOccurs=\"3\"" for <xkms:KeyUsage/> element may 
> prevent schema 
> extension
> in the future, I would suggest to change this to 
> "maxOccurs=\"unbound\"".
> 
> Most likely it's already too late to for any changes but I 
> would like to 
> note these issues.
> Also I wonder if there exist any kind of interop test suite 
> (I could not 
> find one on the XKMS
> working group page).
> 
> Thanks,
> 
> Aleksey Sanin
> 
> 
>

Received on Wednesday, 6 August 2003 15:03:00 UTC