RE: [dss] Core spec: client-side transforms, etc.

["Edward Shallow" <ed.shallow@rogers.com>]

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