Re: [dss] requirements draft 4

[Trevor Perrin <trevp@trevp.net>]

At 08:45 PM 4/30/2003 -0400, jmessing wrote:

>This is a fundamental error in my view.
>
>Signatures are particularly legal creatures. I can find no other real 
>world purpose or function. It seems evident to me that one signs in order 
>to create legal obligations and gain the ability to enforce these in the 
>courts, which are also legal institutions.

Let's call those "legal signatures" to distinguish them from "cryptographic 
signatures", which are just a bit of data through which a key commits to 
some other piece of data.

Cryptographic signatures are used to implement legal signatures, but can 
also be used for other things (such as authenticating yourself to a 
service, or authenticating a message that instructs some entity to do 
something).

Since a legal signature is just a cryptographic signature with a particular 
set of additional attributes, I think our first work item should just be a 
DSS "Core" protocol for cryptographic signatures, which makes no statements 
about what goes into the signature in terms of signed attributes, policy 
identifiers, etc..

Then further work could profile a particular set of signed attributes with 
a specified legal interpretation, and then when the core protocol was used 
to produce signatures with those attributes, it would be producing a legal 
signature.  But if a different group profiles a set of signed attributes 
for code-signing or something, then their DSS would be using the same core 
protocol, but would be producing code-signing signatures (which may or may 
not have any legal ramifications).

So I sort of think we have a 3-layer stack:

  Signature Profiles
---------------------
  Core DSS Protocol
---------------------
  Protocol Bindings

The Core Protocol specifies the mechanics of sending data to be signed or 
verified and receiving the result.

Protocol Bindings specify how transport, authentication, confidentiality, 
and integrity are supplied to the core protocol.

Signature Profiles specify the interpretation of signatures produced by the 
core protocol.

I think we should first tackle the core protocol, since that's the one 
piece everything depends on - then we (and other people) could supply 
bindings and profiles to make the core protocol useful in particular 
environments.



>Removing the necessary legal semantics to create and enforce signatures 
>from a standard ostensibly designed for signatures makes no sense to me at 
>all.

I'm not saying remove them - I'm saying we don't need to deal with them 
while we first focus on the mechanics of delegated signing.


>The underlying technology of digital signatures is not new. The unsolved 
>challenge is to have the technology actually employed for legal and 
>business purposes.

There's enough unsolved challenges in the requirements to keep us occupied 
for awhile: define an XML timestamp format, define schemas to transport 
fragments of various (perhaps partially transformed) documents or document 
hashes along with indications of which parts of them should be (perhaps 
further transformed) and signed, define error codes, handling of 
synchronous and asynchronous responses, how to indicate where the signature 
should be placed in the produced document, how to indicate ID references to 
the DSS server, etc...



>The reformulated language as an approach will do nothing to further the goal.

Well, I think it gives us a manageable problem to solve which isn't the 
whole problem, but is a good first step, and opens the door to follow-on work.

Trevor