RE: [dss] client-side hashing

["Kaliski, Burt" <BKaliski@rsasecurity.com>]

In the context of blind signatures, I was thinking of (b), but more broadly
key selection could include (a).

I like your suggestion of a "getCapabilities" query, and the cross-signing.

The only flexibility that's needed in the protocol at this point to support
blind signatures is for the requester to be able to learn the server's
capabilities in advance of requesting a signature. (At least for RSA-based
blind signatures this is the case since the request is followed immediately
by a response, with no further interaction; other schemes may involve
multiple exchanges.)

-- Burt

-----Original Message-----
From: Pieter Kasselman [mailto:pkasselman@baltimore.com]
Sent: Thursday, February 06, 2003 4:34 AM
To: Kaliski, Burt; 'Trevor Perrin'; dss@lists.oasis-open.org
Subject: RE: [dss] client-side hashing


Hi Burt, when you mention key selection protocol, does that mean:

a) A method for selecting the client key to be used by the DSS server?
b) A method for selecting the DSS server public key?

In the case of (a) I am not sure if we need a key selection protocol (at
least for a first version of the DSS server). The choice of a specific key
can be indicated through the choice of a specific policy. If the end user
has multiple keys and identities he may select between them by indicating
different policies. 

In the case of (b) that can possibly be included as part of a general query
on the capabilities of the DSS server. For instance the client can send a
getCapabilities request and receive a list of capabilities, including a list
of DSS public keys. The response can be signed by one of the keys (or all of
them). The client will need to be capable of verifying the signatures
(implying some kind of trust point). We could also rely on some underlying
protocol to provide this information instead of explicitly including it in
the DSS protocol.

Regarding blind signatures it would be interesting to know how widely they
are used and what the market demand are for them. If there is little demand
I am not sure that we should spend to much energy specifying a very flexible
protocol just to allow for something that is rarely used (the 20-80 rule).

Cheers

Pieter