W3C home > Mailing lists > Public > www-xkms@w3.org > May 2003

RE: XML Key Management Specification Last Call - need review/feed back

From: Robert Zuccherato <robert.zuccherato@entrust.com>
Date: Thu, 22 May 2003 15:08:15 -0400
Message-ID: <BFB44293CE13C9419B7AFE7CBC35B93903E27D99@sottmxs08.entrust.com>
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

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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:41 UTC