[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Core spec: client-side transforms, etc.
Folks, This is what I was afraid of ... i.e. a re-opening of fundamental decisions which date back months ago as we are attempting to go to another Committee Draft. In our quest for simplicity (admirable) we are now questioning the signature-centric verus document-centric view of the protocol. This fundamental precept should have been put to bed in the "face-to-face" yet it languishes as an issue to this day. If you are soliciting input, here is mine (forgive the SoapBox): - I had always lobbied for the document-centric view and its inclusion in the core primarily motivated by a desire for simplicity (especially as it applied to Verification) - I have no problem with the signature-centric view, and see a place for it in the core for those special circumstances (e.g. big documents ... but isn't that an exception scenario ?) - However, when forced to weigh complexity versus features, the EPM Profile very early on decided to push simplicity in its Profile - From the very first draft of the EPM Profile (July 2004), the Base64Data choice on the Document element was mandated as the "only" option for all the reasons we have been debating these last 8 weeks. - The EPM Profile does not support any client-side transforms and in fact even constrains the use of the <SignedReferences> OptionalInput for similar reasons. - When faced with the tradeoffs of forcing clients to actively splice out document nodesets and signatures versus the relatively simple task of finding signatures and using DTD fragments, we chose the latter realizing that the majority of desktop solutions and crypto librairies out there would be producing whole document constructs and it would be these very applications that DSS implementations would be adding value to (at least in the Verification scenario). - On the flip side when it comes to delegated signing scenarios, isn't the whole point of a DSS server-side signing solution to remove and hide complexity from the client ? Isn't it advantageous and beneficial to be able to simply throw a document "over-the-wall" at a DSS implementation for signing ? And clearly isn't it also desireable to get the signed artifact back in one piece with which the client need do nothing ? - We believed so strongly in these assumed scenarios that the EPM team actually constrained Document occurrences to 1 for the sake of simplicity and introduced the notion of "signing templates" to make up for the functional shortfall. In summary let's continue this debate to resolution, but please do not remove the document-centric notions and support we currently have in the protocol. This I believe would be a step backwards. Ed -----Original Message----- From: Trevor Perrin [mailto:trevp@trevp.net] Sent: July 26, 2005 5:43 AM To: DSS TC List Subject: [dss] Core spec: client-side transforms, etc. Guys, I'm trying to understand how the core doc has evolved in the last few months. Since the document is in flux, I may not understand things correctly, but I have some questions: It seems we're disallowing clients from applying client-side transforms. Are we also disallowing clients from sending "Input Documents" which are fragments of larger XML documents? Is the goal of these changes to simplify/enable application of server-side transforms? As I recall, the most important server-side transform, canonicalization, can easily be made to work with client-side transforms (including extraction of fragments) as long as clients send all relevant namespace context (i.e., clients add inherited namespace prefixes as attributes of the root node of an Input Document) [1]. So I presume the rationale for the above changes is that more complex server-side transforms might require XML document context which is not present in a transformed or extracted Input Document. This was a problem with the core spec as of wd-30. In hindsight, I think it could be solved one of two ways: A) Limit the server-side transforms the server can apply as part of basic processing B) Require a client to always send full, untransformed documents so the server can apply any server-side transforms. In my opinion, the ability to send partial and/or transformed input documents is crucial. It allows a client to request a signature on a small portion of a larger document, or access a generic server which lets clients request signatures on any sort of transformed document. In contrast, the risk of a server not being able to apply a transform because the client has applied an incompatible transform seems easily managed with Profiles. Profiles will specify rules about the Input Documents clients can send. If clients break these rules (by applying an incompatible transform, by sending the wrong XML document, by sending a fragment when they should have sent a whole document or vice versa), then they are noncompliant, and there's nothing to be done. So it seems to me that (A) would have been a minimal change to core preserving important functionality. The path we're on, (B), seem to me an unnecessary re-engineering of the signing protocol which loses much functionality. One argument from the archives for (B) is this: "the only case where client transformation seems to make sense is where the client sends the document hash instead of the document" [2]. However, consider these cases: - the server wants to apply additional transforms to an Input Document which is a fragment of a much larger XML document - the server wants to review or archive what it is signing - the client doesn't know which hashing algorithms are acceptable for the signature - the client is a lightweight device which doesn't want to implement canonicalization and hashing Perhaps this is a related issue, perhaps not, but I'm also concerned by the proposal to remove 3.2 and 3.3, which describe simple algorithms clients can use to produce enveloping and enveloped signatures with a server that implements basic processing. These algorithms are efficient and simple for the clients and have zero impact on servers. The alternative is for clients to send all enveloping and enveloped documents to servers along with instructions on how to compose them. There is no need to perform such simple operations on servers, and much disadvantage in terms of bandwith, the server complexity of implementing <SignaturePlacement> and <EnvelopingSignature>, and security (exposing data to the server you may not want it to see). This gets back to the distinction between a signature-based vs. document-based protocol [3]. The DSS signing protocol was primarily signature-based: it took the inputs to a signature and returned a signature. This gave a minimal core protocol, where the server handles signature creation, and the client handles all application issues around preparing signature inputs, and doing something with the signature after its creation. However, optional inputs were provided so that profiles can shift some of these burdens to the server, thus providing document-based functionality as enhancements to the core protocol. Now, we seem to be moving away from the signature-based aspect, towards a protocol that always sends and receives entire XML documents. While I saw mention in the archives of moving things like client-side transforms to profiles, I think it makes more sense for core basic processing to be the *simplest* level of functionality, i.e. simply "produce a signature", while leaving the complexity of pre-signature operations (i.e. server-side transforms) and post-signature operations (i.e. enveloped / enveloping signatures) to Optional Inputs and profiles, as much as possible. Trevor [1] http://lists.oasis-open.org/archives/dss/200505/msg00058.html [2] http://lists.oasis-open.org/archives/dss/200506/msg00020.html [3] http://www.oasis-open.org/archives/dss/200505/msg00034.html --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]