-----Original Message----- From: Trevor Perrin [mailto:tre...@trevp.net] Sent: July 8, 2003 12:15 AM To: Edward Shallow; 'Gray Steve' Cc: roge...@canadapost.ca

These are good things to debate, I wouldn't mind doing it on the list where more people could observe and join in, if you wanted to take it there..

<ed>Yes ... Go ahead and post these exchanges to the group.</ed>

At 11:13 PM 7/7/2003 -0400, Edward Shallow wrote:

I hope you saw my mails of the 3rd, which made a stab at answering that: http://lists.oasis-open.org/archives/dss/200307/msg00019.html http://lists.oasis-open.org/archives/dss/200307/msg00020.html

I think that question doesn't pertain to DSS. DSS is a protocol that supports many different use-cases, and could be deployed in many different systems, in many different legal regimes, to produce many different types of signatures, that accomplish many different goals.

In some of these contexts, DSS-created signatures may be non-repudiable. In others, they may not. DSS addresses only the mechanics of delegated signing/verifying, and does not mandate that the signatures created or verified have any particular meaning.

So while certain profiles of DSS, and some systems that build on DSS like EPM, may take non-repudiation into account, by mandating authentication and key management technologies that are compliant with particular legal regimes, and archiving data in a prescribed manner, and so on, I think DSS aims only to create Signing and Verifying protocols that address: INPUT: document OUTPUT: signed document and INPUT: signed document OUTPUT: yes/no [this is an over-simplification]

In other words, DSS is a building block, it's not a whole building like EPM is. I think NR is a "holistic" property that depends on an entire architecture and the legal context it's deployed under, and it doesn't make sense to ask whether DSS by itself achieves that property. DSS could be part of a system that achieves that property, but it doesn't have to be.

Asking whether DSS supports NR is like asking whether TCP/IP supports email. TCP/IP handles packets. DSS handles signatures. What these packets or signatures accomplish in higher-level protocols and systems is out of scope to the lower-level protocol.

<ed> I like your analogy, but I will use it to support my argument. If the DSS foundation stays at the TCP/IP level then you will be forcing the various profiles up into the TCP/IP payload or body. In SOAP's request/response RPC encoding style (or even in SOAP's document-literal style) you must define the XML structure of your requests and responses. One cannot compose a WSDL leaving the payload largely freeform. This is what you will end up doing and the profile specifics may seem to you to be transparent to DSS, but they won't be to the implementor. They must be defined right down to the primitive SOAP or schema data types. Each profile definition will end up right in the body the DSS strcuture, possibly selected via <choice> or identifer constructs. Contrary to your assertion, you will create a confusing and unmanageable profile inventory, which in the end will be too overbearing and confusing to use. Not to mention the endless profile updates you will staddle the team with. </ed>

There currently do not exist client/server protocols for creating and verifying digital signatures, or for XML timestamps. DSS is going to define these.

<ed> Not entirely true. RFC3161 timestamping describes the request and response structures in their entirety. Shipping the request and receiving the response is simply a transport issue. Even status and completion codes are defined. Putting these into HTTP or SOAP is trivial. As for XML rendering of timestamps, I believe Vincent Girier ISSE, as well as Entrust have submitted viable proposals in this area to your own committee. Are you intending on recasting or replacing those submissions as well ? </ed>

We've identified many use cases where such protocols would be useful. For example: - the client wants corporate approval for a document. The client submits the document, and sometime later retrieves the signed version. - the client doesn't want to carry his email signing key around with him. The client stores the signing key at the server and then when he wants to sign an email, sends the hash of the mail to the server and asks the server to apply his key for him. But these signatures aren't for legal purposes, the client just doesn't want people to spoof his mail. Similar products exist. - a notary authenticates clients and then signs, using its own key but inserting the client's name. Similar products exist.

<ed> I don't believe internally-deployed corporate signing services can be described as truly delegated. These signatures would more than likely be created with dedicated crypto infrastructure using corporately managed keying material, and likely NOT be delegated to a 3rd party. These corporations would be infintely more accountable for those signatures. As I have previously stated, we encourage the deployment of a non-logging departmentally-owned version of the EPM "within" the ministries of the government. This we do NOT describe as "delegated signing". The Web Service interface is not exposed outside the deparmental walls. They actually use it as a transaction level VPN to authenticate themselves to each other. </ed>

- a corporation doesn't want to give its code-signing key to developers for signing applets and ActiveX controls, and the corporation wants a record of when this key is used to sign something, and who requested the signature (I've worked for 2 companies where the private key was on a floppy in my desk, and a lot of other developer's desks as well). So the corporation hosts a DSS service that the corporation's developers can access to sign downloadable code modules.

You've asked similar questions a number of times, about how is DSS going to differentiate itself and add value to pre-existing standards. But the standards you mention are not request/response protocols for the production and verification of signatures, so I'm mystified by what standards you think DSS is redundant with.

<ed> I agree that the standards I quoted don't contain transport semantics. But as you know, they do address content and payload formatting, while SOAP addresses endpoints and payload delivery. What is left ?

You are now down to a very thin "value" layer. Amongst other thinsg, the EPM does address this "service requesting" you speak of through the basic operations and their options. Why can you not acknowledge that ?

On the specific standards redundancy subject: I've stated at least twice before now, that you are not adequately assessing the SignaturePolicy capabilities within ETSI 101 733/903 and RFC3126.

Your example below in the paragraph with the Ali...@Acme.com reference makes it clear you don't see the overlap with the objectives of SignaturePolicy. "this document has been reviewed and approved" is an "intent phrase" or "commitment rule".

Are you going to reinvent SignaturePolicy ? </ed>

You're welcome to propose that to the list.

You claim "delegated signing" is incompatible with NR. I disagree. If NR means anything, it means that the client should be held responsible for things signed with the public key.

<ed> Things aren't signed with one's public key, they are signed with one's private key. </ed>

If this responsibility was contingent on the client's private key management practices, then it would be easy for the client to repudiate a signature by claiming lax practices.

Example:

Alice gives her private key to Bob. Alice signs a contract with Charlie Alice tries to repudiate the contract Alice points out that Bob has her private key. Thus, since the private key was not in her sole possession, the signature cannot be uniquely assigned to her. Alice has successfully repudiated the contract.

<ed> Absolutely incorrect. Alice is obliged to notify the Certificate Authority the moment key compromise has taken place.

If she does not, she would have broken a fundamental precept of every Certificate Policy on the planet.

She is also obliged by that same CP not to disclose the secret password or give away the keying material, both of which she has done. It is similar to the passport theft scenario, where you are obliged to notify the passport office of passport theft the moment you find out. Conscious violation is an extreme, but open and shut case.

</ed>

Thus, if you want NR, you have to hold Alice accountable no matter what she does with her private key.

<ed> These obligations to protect your key and secret should not be news to you ? Clearly if one happens to have a clear disdain for PKI, one might find this objectionable, but that is the current state of this popular technology, which the largest players in the industry are now making pervasive (MS and Adobe). </ed>

If she wants to store it on a server and access it there, that's her own business.

<ed> She I obliged to keep it under her protective custody. In fact one of the largest PKI supplier's in the world supports a roaming certificate served from a profile server, which they take emormous pains to double encrypt and re-create on the signer's workstation just so they can claim the user signs while in possession of the keying material. I invite you to study the Entrust TruePass architecture.

There are other examples of this in the industry which show the clear concern for delegated signing and its obvious weak authentication exposure. Why have a vault if you are going to let people in with a simple weak password. </ed>

Disagree. Different profiles won't affect the protocol itself.

<ed> Impossible. WSDL request parameters will have to be affected in order to describe the nuances of each profile pre-requisite. </ed>

They'll affect the contents of the signatures that the protocol produces, what bindings the protocol is transported over, what external requirements are placed on the behavior of protocol participants (such as having to archive data, or sign using a particular key), and how these signatures are interpreted.

TCP/IP doesn't change to take into account new applications. Rather, it carries a payload and higher-level protocols can stuff different things into this payload.

Similarly, the signatures DSS carries can have all sorts of different policies and attributes attached to them, and can mean different things in different contexts, and the DSS servers that process these payloads can do all sorts of subsidiary things like archiving them, but the DSS protocol doesn't care.

<ed> Once again, you overlap with the "terms and conditions" concepts embodied in the SignaturePolicy work of the ETSI. </ed>

Whether a DSS signs a document to say "this document has been reviewed and approved",

<ed> ETSI 101-733/903 SignaturePolicy CommitmentRules. </ed>

or signs it to say "this document comes from Ali...@Acme.com, who authenticated herself to me", or signs it with the client's private key, is a matter of signature contents, it doesn't affect the protocol. Whether the server archives the document in a NR DB, or what key he signs with, or what directories and CRLs he consults for validating cert paths, and so on, similarly doesn't affect the protocol.

I don't think we want to put profile complexity into the protocol. Rather, we (or at least I) would like EPM to consider itself as a profile of DSS, for those operations such as Verify and external Sign in which we overlap.

In other words, if EPM has the requirement that Verify operations are logged in a NR DB, that's fine, but it doesn't affect DSS. We just define protocol messages, and what an EPM service does to handle these messages is your own business.

We would like to define a protocol in which clients can request that servers produce and verify signatures in the XMLDSIG format.

Since this format is complicated, we have to allow clients to say things like: - sign these 2 URIs, and these 3 elements within this document, and this element within the document which I'm just going to send the hash of, because the element itself is too large (but here's the transforms I applied before hashing, which you need to know so you can insert them into the final ds:SignedInfo) - apply these transforms to the URIs, and this transform to this element, and so on - insert the resultant signature at this point in the document - but don't bother returning the whole document, just the signature, because I'll splice it into the resulting document myself.

This is an extreme example, but it shows the complications we have to consider when producing and verifying XMLDSIG signatures.

The point is not that XMLDSIG needs "help". The point is that the protocol aspects of how a client sends data to be signed/verified are complicated because XMLDSIG is complicated, and handling these aspects will be DSS's greatest challenge, and our greatest contribution.

<ed> You're in the domain of desktop authoring tools where this signing is really taking place. Please familiarize yourself with Microsoft's InfoPath XML form authoring tool, as well as Adobe Acrobat's V6 signing framework.

They don't need to be told how to sign documents, parts of documents, hashes of docments, etc ... This is the domain of the authoring tool and subject to the ergonomics of its user interface and usage scenarios. Very subjective territory.

P.S. You're too late anyway. See also MS Office 11 Beta and StarOffice 6.x

</ed>

If DSS handles all these mucky details, then EPM and other people can tackle the more interesting, higher-level problems of building services that augment the DSS protocol with NR logging and other things.

We aren't trying to reinvent XMLDSIG, we're trying to support it. You keep comparing DSS to things like XMLDSIG, or XAdES, but those are inputs and outputs to the DSS protocol, they aren't comparable to the protocol itself.

<ed> You are being inconsistent. You earlier stated applying transforms to URIs and signature insertion were part of DSS' strongest offering ? Do you not think XMLDSIG can address these requirements ?

</ed>

I don't know where you get the idea that DSS is competitive with pre-existing signature formats.

The 3 things mentioned in our charter, I still think.

face-to-face.

What do you mean "start where EPM" leaves off?

My preferred relationship would be for EPM to view itself as a profile of DSS, for those operations where we overlap. As for those operations where we don't overlap, EPM is on its own.

It seems the disagreement is that you think we should expand our charter to include all of EPM ...

<ed> Never said that. In fact we are still concerned (for OASIS sake) with exactly DSS intends to accomplish and were hoping to steer it in directions which would add greater value and not sit on the shelf. </ed>

but I'd like to keep it how it is, and solve the more narrow

<ed> Well chosen word, narrow is exactly what I would call it. Deriving value will be a challenge under these constraints. </ed>