About the next meeting

[Juan Carlos Cruellas <cruellas@ac.upc.es>]

Dear all,

As next Monday  seems to be holidays in USA, the next
meeting will be re-scheduled for Monday June the second.
In the meantime I propose  to progress in the items that
appeared in the agenda I circulated for this conference, discussing
them by email, and trying to arrive to the next meeting in the best 
position that we can.... 

Just one comment on Item 5. If nothing is received on the additions
to the XKMS comments  22 of May the latest, I propose to send the original
comment made
by Robert:

---TEXT POSTED BY ROBERT:

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.

---END OF TEXT

Regards

Juan Carlos.