[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] requirements draft 4
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]