RE: [dss] client-side hashing

[Pieter Kasselman <pkasselman@baltimore.com>]

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

> -----Original Message-----
> From:	Kaliski, Burt [SMTP:BKaliski@rsasecurity.com]
> Sent:	05 February 2003 19:03
> To:	'Trevor Perrin'; dss@lists.oasis-open.org
> Subject:	RE: [dss] client-side hashing
> 
> Good idea. If the client can get the server's public key in advance, the
> digest method can include the step of "blinding" the hash value.
> 
> I'm not suggesting blind signatures as a requirement, but just as
> something
> to consider when developing the architecture for the server.
> 
> Based on the discussion so far, it looks like the architecture should
> provide a means for the client to obtain the server's public signature key
> in advance of supplying the value to be signed. Indeed, this may have
> other
> benefits; the client might have preferences as to algorithm, key size,
> available certificates, etc. So an optional key-selection protocol may be
> a
> useful feature.
> 
> -- Burt
> 
> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: Wednesday, February 05, 2003 12:51 PM
> To: Kaliski, Burt; dss@lists.oasis-open.org
> Subject: RE: [dss] client-side hashing
> 
> 
> At 09:30 AM 2/5/2003 -0500, Kaliski, Burt wrote:
> >Is there any interest in a blind signature service? In such a service,
> the
> >server would return a digital signature without ever seeing the hash.
> This
> >would prevent the server from subsequently "linking" the digital
> signature
> >with the user who requested it.
> 
> Would be neat.  The only scheme I'm familiar with, Chaum's RSA blinding, 
> requires the client to know the server's public key, which is a slight 
> inconvenience.  And is patented until 2005.
> 
> If the protocol is generic enough that a client sends a list of 
> ds:References, and a selector for what type of signature he wants (CMS,
> XML 
> DSIG, etc.), then might protocol support for this be as simple as just 
> specifying a new ds:DigestMethod? 
> -http://www.w3.org/2000/09/xmldsig#sha1WithRSABlinding
> 
> Trevor 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com