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

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

Trevor, Konrad,

Regarding 1)

As I understand it you are proposing to support client side transoforms but
only in the case where the data is transferred as an octet string in based64
for signing by the server without any transforms.

Any objections to this?

Regarding 2)

I agree that we need to consider this carefully.  As agreed at the meeting I
ask Konrad to send out a description of this issue and the possible changes
as a threatd separate from the next version.

I urge you two to work together to get as speedy resolution to this.

Nick

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 28 July 2005 08:59
> To: Konrad Lanz
> Cc: dss@lists.oasis-open.org
> Subject: Re: [dss] Core spec: client-side transforms, etc.
>
>
>
> Konrad and I had a good talk, which narrowed my concerns.  We discussed
> two things -
>
>
> 1) Client-side transforms
>
> Konrad pointed out that client-side transforms can produce octet streams
> or even node sets which are not XML, and thus cannot be transmitted in
> <InlineXML>, <Base64XML>, or <EscapedXML>.  Thus, *transmission*  of
> intermediate transform results causes difficulties.
>
> Konrad also pointed out that intermediate transform results may not
> contain enough context from the document to allow certain server-side
> transforms to be applied.  Thus, *server processing* of intermediate
> transform results causes difficulties.
>
> After thinking about this, I think these aren't really problems, just
> acceptable limitations:
>
> If your client-side transform produces non-XML, then it's obvious you
> can't send the result as XML.  But you should still be able to send it
> as a hash or <Base64Data>.
>
> If your client-side transform is incompatible with certain server-side
> transforms, then the server can't apply those transforms.  It should be
> up to profiles to allow/disallow client-side or server-side transforms
> as appropriate.  There are use-cases where you only want client-side
> transforms, only want server-side transforms, or want mixes of both.
>
> Anyways, protocol and server support of "client-side transforms" is
> simple - the server just copies the received <ds:Transforms> element
> into a <ds:Reference> element.
>
> For these reasons I propose <ds:Transforms> be reinstated in
> <dss:DocumentBaseType> instead of banished to <dss:DocumentHash>.
>
>
> 2) "Document splicing" for enveloped/enveloping signature (3.3.2, 3.3.3)
>
> Konrad expressed a desire for the server to always return verifiable
> signatures (i.e. signatures with all enveloping and enveloped documents
> attached), so the client would not have to do splicing itself, or
> trigger an optional input to request server-side splicing.
>
> I believe this would mean eliminating 3.3.2 and 3.3.3, and moving the
> functionality currently described in <SignaturePlacement> and
> <EnvelopingSignature> into core basic processing, while adding an
> optional inputs that requests returning an "unspliced signature" instead
> of the spliced one.
>
> One of Konrad's concerns with the current approach is that it might be
> error-prone for clients to do splicing, as they might forget or do it
> incorrectly.
>
> Another concern was "datatype normalization".  I'm probably not
> explaining this right, but the idea was that "datatype normalization"
> might cause the value the server signs to be different from what the
> client thought it sent, so that the client splices the signature with a
> slightly different document than was actually signed.
>
> I'm not convinced by these arguments.  Clients might forget or do many
> things incorrectly; that's why we write good specs and do testing!  I
> agree the specs could be more detailed here, but I don't see why this is
> intrinsically error-prone.
>
> As for datatype normalization, I don't understand.  Is this a problem
> with an unreliable transport, or incorrect server parsing, or the
> presence/absence/difference of schemas on the client and server ends?
> Won't all these cause other catastrophic problems?
>
> In any case, the signing protocol was designed around the notion of
> creating and returning a signature.  If you want the server to do
> something additional, like document splicing, you access it through
> options which leave basic processing mostly untouched.  This was in
> accord with the "minimal core" philosophy, where the core provides a
> simple, mostly unchanging base which options add to, instead of
> replacing or redefining.  I think the belief was that such a core is
> easiest to build off of when spec'ing, implementing, and interoperating.
>
> That's a fuzzy argument but it's getting late.  Well, the more important
> point is this:  We need extremely good reasons, and a well-analyzed
> proposal, before making changes this big.
>
> Anyways, I hope this makes my concerns clearer.  Konrad, I'd much
> appreciate it if you can weigh in with what I'm missing or further
> arguments.
>
>
> Trevor
>
> ---------------------------------------------------------------------
> 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
>
>
>