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

["Nick Pope" <pope@secstan.com>]

Ed,

Don't panic!

I think we have in what was discussed at the last few meetings the agree
basis of the way forward.  I think we are now at the stage of just ensuring
that this is worded in a clear and concise manner with all the loose ends
tied up.

Nick

> -----Original Message-----
> From: Edward Shallow [mailto:ed.shallow@rogers.com]
> Sent: 26 July 2005 16:54
> To: 'Trevor Perrin'; 'DSS TC List'
> 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
>
>
>
> ---------------------------------------------------------------------
> 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
>
>
>