- From: Robert Zuccherato <robert.zuccherato@entrust.com>
- Date: Thu, 22 May 2003 15:08:15 -0400
- To: "'Shivaram Mysore'" <Shivaram.Mysore@Sun.COM>, www-xkms@w3.org
- Cc: "'stephen.farrell@baltimore.ie'" <stephen.farrell@baltimore.ie>, "'cruellas@ac.upc.es'" <cruellas@ac.upc.es>
The DSS TC would like to thank the XKMS WG for the opportunity to comment on the Last Call Working Draft. We have one comment related to a potential enhancement to support our use cases. A DSS service may produce signatures (such as XML-DSIG and CMS signatures) for its clients - if it authenticates the client, it may attach the client's name as a signed attribute to the signature - this way a client can produce signatures that are associated with himself, without needing his own key pair. So it would be nice if a relying party can query an XKMS service on the DSS client's name, and receive back the DSS service's key, but the XKMS client would need to be told that this key is not in the sole possession of the DSS client, but must be associated with the DSS client through a signed attribute. Two options appear feasible. This could be done by adding a new "DelegatedSignature" value to the <KeyUsage> element: <KeyUsage>DelegatedSignature</KeyUsage>. So for a given protocol that uses signatures, an XKMS client could query for <KeyUsage>DelegatedSignature</KeyUsage> as well as <KeyUsage>Signature</KeyUsage>. This is simple, but would require a change to XKMS. Alternatively, the same an extra application URI could be defined for the <UseKeyWith> element, for every protocol that uses signatures, to denote the delegated signature version. This requires the definition of an extra URI for each protocol that uses signatures and thus seems more difficult to support, in general. It would not require a change to XKMS though.
Received on Thursday, 22 May 2003 15:08:34 UTC