|Trevor Perrin||Jul 9, 2003 9:59 am|
|Trevor Perrin||Jul 9, 2003 10:38 am|
|Trevor Perrin||Jul 9, 2003 7:55 pm|
|Trevor Perrin||Jul 9, 2003 9:41 pm|
|Gray Steve||Jul 10, 2003 12:17 am|
|Nick Pope||Jul 10, 2003 1:49 am|
|Trevor Perrin||Jul 10, 2003 2:03 am|
|Trevor Perrin||Jul 10, 2003 2:11 am|
|Nick Pope||Jul 10, 2003 2:33 am|
|Trevor Perrin||Jul 10, 2003 9:49 am|
|Trevor Perrin||Jul 10, 2003 12:07 pm|
|Trevor Perrin||Jul 10, 2003 2:57 pm|
|Nick Pope||Jul 11, 2003 1:46 am|
|Gray Steve||Jul 11, 2003 8:53 am|
|Trevor Perrin||Jul 11, 2003 11:20 am|
|Subject:||Fwd: RE: UPU CPC EPM Positioning Proposal vis-a-vis the OASIS DSS|
|From:||Trevor Perrin (tre...@trevp.net)|
|Date:||Jul 9, 2003 9:59:40 am|
Forwarding from Ed -
Date: Wed, 09 Jul 2003 12:13:36 -0400
Trevor, ... (please post to list)
Carlisle's "Corporate Seal" 2.1 and "Identified Requestor" 2.3 use cases are closely related, as he states in the use-case itself. The value is definitely coming from an "inside (the corporation) looking out" perspective. The Government of Canada also saw this value and requested the S2S EPM. This is the subset of the EPM I spoke of that actually uses the "External Sign" operation described in our WSDL. This Sign however was mandated (by the Canadian Security Establishment (CSE), one of only 2 FIPS-140 certified accreditation labs in North America) to take place "within" the departments' of the GoC using departmentally-held and keying material. Each department within the government was mandated to use "their own" internally-controlled and deployed "Corporate Signing" service (using the EPM S2S Sub-Service of the Government Secure Channel as the vehicle).
In my opinion, this description above is what Carlisle seems to be alluding to. This very much constrained and controlled definition of "delegated signing" we would condone. Your description of "delegating signing" is an enormous leap from the above definition. I wonder what Carlisle originally envisioned ?
To take this all the way out to a definition where some 3rd party DSS signing service "holding the private keys of the corporations' of America" is what we find totally off the mark.
Perhaps this is once removed from the protocol itself, but a huge leap from one to the other.
I invite you to clarify Carlise's and the team's intent and see if it coincides with ours.
you'll have to hunt for my responses, sorry-
At 05:22 PM 7/8/2003 -0400, Edward Shallow wrote:
Her goes another round ... Your arguments will have to be brought down to ground level where facts can be used to resolve differences. See responses intermixed as <ed> ... </ed>.
Steve, please post to list.
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>
I'll wait for Steve to post, then follow-up.
At 11:13 PM 7/7/2003 -0400, Edward Shallow wrote:
Some high-level comments, so don't have to wade thru the document.
- you have not as yet addressed the fundamental scope question as to whether non-repudiation is in or out.
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>
If the business acts of signing and verifying have no larger motive, then what is another low-level protocol going to do to add value and increase adoption ?
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>
I don't think we've decided what the XML timestamp format should look like. I'm sure we'll take the input documents into account, and maybe adopt one of their formats wholesale if it's adequate.
At the moment we're just deciding on requirements and scope. A standard XML timestamp format doesn't exist, so we intend to standardize one.
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>
I was giving examples of use cases where a DSS protocol might be useful, since you were questioning that. You're right, some of these things might not be described as "delegated signing", DSS has other use cases besides that.
- 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 ?
Protocols for creating and verifying signatures. I.e., the client wants to produce a signature, but for whatever reason doesn't have the ability to do so himself and must enlist a server. Same for verifying.
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 ?
what am I not acknowledging, exactly? I agree that EPM does some of the same things as DSS. That's why there's overlap, and why we're discussing how to rationalize that overlap.
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.
What would you like to see me/us doing that would make you think we were adequately assessing this?
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".
Okay. Then if a DSS server is producing a signature with that intent, in a format like XAdES that allows such an attribute, then it should put that SignaturePolicy in the signature.
Are you going to reinvent SignaturePolicy ? </ed>
No. The request/response protocol is going to ignore it, like it ignores any other signed or unsigned attributes the server chooses to add into the signature.
Perhaps the charter itself should be revisited in this area.
You're welcome to propose that to the list.
- if the answer to the first question above is that NR is in, then the 1/3 of DSS' mandate intending to perform "delegated signing" will be out
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.
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.
Right, but in a repudiation attempt, Alice is the *attacker*. You can't trust Alice to protect you from herself. If non-repudiation depends on Alice keeping her private key private, then it's easy for Alice to repudiate signatures, and almost impossible for Charlie to prove the negative that no-one else ever gained access to Alice's private key.
The only reasonable way to proceed is for Alice to enter some contractual relationship where she agrees to assume liability for *anything* that verifies with her public key, up to some limit. In this situation, Alice can manage her private key however she wants.
Lest you think I'm inventing things, many reputable crypto-technologists have similarly "repudiated" the concept of non-repudiation as being unworkable: http://www.cryptoapps.com/~peter/part2a.pdf http://www.counterpane.com/pki-risks.pdf
If she does not, she would have broken a fundamental precept of every Certificate Policy on the planet.
Yup. And she would have repudiated her signature.
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.
Sure. Alice says "Bob has my private key". So the signature can't be non-repudiably bound to me. Alice walks away scot-free. Open and shut. Either that, or the judge says "I don't care, private key security is your responsibility", in which case Alice is free to do whatever she wants with her private key. Like store it on a DSS server!
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.
I'm familiar with these - RSA has a product, SingleSignOn.Net, Arcot, IETF's SACRED, SecureComputing, Hushmail. In most cases the private key is encrypted with a password, so it would be easy for the server to brute-force, and the claim that the private key is in the client's sole possession is debatable.
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>
It was an Entrust guy who started this TC, and made the initial submission, and a different Entrust guy who submitted the Identified Requestor use case which you dislike so much. And a 3rd Entrust guy who just today argued:
"The rationale behind a services-oriented architecture is cost-reduction: the cost of maintaining complicated clients. The instant a complicated client is deployed, it is wrong. And the activity of replacing wrong clients is costly and unreliable. Hence, the argument goes, deploy clients that are so simple, they can't possibly be wrong, and do the complicated stuff in a server setting, where there will be many fewer instances of the function and the software environment will be much more stable and predictable."
which pretty clearly explains why a server-side approach has some advantages over client-side PKI.
- the whole notion and role of profiling will probably lead to unmanageable permutations and combinations of service and request options,
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>
dunno what this means. I don't think the TC has agreed (or disagreed) or even discussed whether we're using WSDL, and we probably don't mean the same things by profile.
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>
No. DSS will leverage those concepts. A DSS will produce a signature. This signature might have an ETSI SignaturePolicy inside of it.
DSS is going to standardize a protocol for producing signatures. We're mostly not going to invent new stuff that goes inside these signatures, since we can rely on the good work of people like XAdES etc..
This is a hugely important division, and maybe this is the thing I haven't communicated well. From the point of view of the request/response protocol, signature contents like SignaturePolicy are opaque. The protocol transports signatures, it doesn't care what's inside of them. ETSI and XAdES stuff and whatever you want can be inside of them.
Whether a DSS signs a document to say "this document has been reviewed and approved",
<ed> ETSI 101-733/903 SignaturePolicy CommitmentRules. </ed>
Yes! That would be a great thing to be inside a DSS-produced signature. You see, we're not as far apart as you think..
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.
the EPM team has already lived thru that and has responded with the extensibility framework described below. We are willing to change and adapt, but can't condone an approach which will result in dozens of overlapping and unmanageable profiles.
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.
- if bridging the gap between CMS/PKCS7 and XMLDSIG/XMLENC is DSS' primary raison-d'etre then my point 4 will have to be delved into much deeper, because the overlap issue will be way out in front. XMLDSIG can perform all the internal and external referencing and transformation one can throw at it. It needs no help in this area.
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.
I doubt I have time.
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.
I was clearly talking about how a *client* tells a *server* what to sign, and communicates the things it wants the server to sign. This has nothing to do with "ergonomics" and user interface, it's a matter of protocol design.
P.S. You're too late anyway. See also MS Office 11 Beta and StarOffice 6.x
Too late for what? Do these define a client/server protocol for creating and verifying signatures? If so, I'd like to know about it.
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.
Detached signatures are academic in the XMLDSIG world. If things get too complex, one can simply break it apart with the EPM's Lifecycle support. This is where the EPM delegates to XMLDSIG and isn't trying to re-invent it's non-XML conterpart,
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 ?
You misunderstood me. The client has to tell the server which transforms to apply to input documents, and where to insert the resultant signature. In other words, the client has to tell the server what type of signature to produce.
We're not inventing our own way of doing transforms or inserting signatures into documents, we're inventing ways of a client telling a server how to do that.
I don't know where you get the idea that DSS is competitive with pre-existing signature formats.
that capability is simply progress and is how complexity will be handled under complex circumstances. The DSS can benefit from learning to appreciate the relative strengths and weaknesses of the XML and binary approaches and not attempt to get both to accomplish the same job.
What does that comfortably leave DSS with in terms of defensible scope ? ... Perhaps a server-side Verify ?
The 3 things mentioned in our charter, I still think.
I still contend the DSS team has a fundamental scope delineation problem which it needs to work through. However, the offer to start where the EPM leaves off is still being extended. Perhaps in the
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>
Okay. That changes the scope of our discussion a little, if you're not just concerned with EPM but with DSS as a whole.
It seems we have 2 themes in this round, at least: - First, you don't like delegated signing. That's fine. Some people do, it adds very little, almost nothing to the protocol, it's a use case we've decided to consider, but everyone who works on the protocol doesn't have to be interested in every use case. - Second, you seem to think we're trying to redefine XML-DSIG or XAdES and similar things. I hope I've conveyed that we're not going to do this. We are a protocol for creating and verifying signatures. XadES and RFC 3126 define things that go inside signatures. We can create signatures that have these things inside them. No problem, no overlap.
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>
Well, I've defended this by pointing out the use cases we will address, and you haven't explained what's wrong with these. We have a TC of about 2 dozen people who presumably are interested in these use cases, and several dozen observers, so some people perceive we have value..