Timestamping Profile Q 3/3: Using signatures to authenticate DSS servers

[Trevor Perrin <trevp@trevp.net>]

It's possible for the client to authenticate a signing/timestamping server 
by verifying the returned signature/timestamp.  This is more efficient than 
using a separate signature, or negotiating TLS.  This approach does require 
a nonce to be sent by the client, and placed in the returned signature - 
see Tim's point #4:
http://lists.oasis-open.org/archives/dss/200308/msg00015.html

I think this is how RFC 3161 is usually deployed.  In fact, this approach 
could work with *any* use of the signing protocol, if you add nonces to the 
signing requests and returned signatures.  However, the efficiency gain has 
some downsides:
  1) in the case of errors, the server's result codes aren't authenticated
  2) any unsigned signature attributes or other signature parts (e.g. 
<ds:KeyInfo>) aren't authenticated
  3) any returned optional outputs aren't authenticated
  4) compared to, say, TLS, there's less confidentiality
  5) The client has to know how to verify the returned 
signature/timestamp.  For example, a timestamping server couldn't return 
just any type of <dss:Timestamp>, it would have to return a particular type 
that the client knows about.

So should we encourage this optimization?  Discourage it?  Allow for it, by 
adding a <Nonce> optional input to the signing protocol?

For now, the timestamping profile says to use server-authenticated TLS.  I 
vote against this optimization, because it seems a little dangerous and 
violates the layering which lets the client be indifferent to the 
particular types of signatures and timestamps the server returns.


Trevor