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

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

Trevor,

I suggest that the default is to apply the canonicalization as required by
XMLSig, but have a attribute set by the client to indicate that any
necessary transforms have been applied by the client and all that the server
is required to do is perform a hash.

Thus, the server is normally free to apply transforms as appropriate but if
the client has applied the appropriate transforms then this can be
indicated.

Nick

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 01 August 2005 00:25
> To: Konrad Lanz
> Cc: dss@lists.oasis-open.org
> Subject: Re: [dss] Core spec: client-side transforms, etc.
>
>
> Konrad Lanz wrote:
> > Hi Trevor,
> >
> > Trevor Perrin schrieb:
> >
> >> 1) Client-side transforms
> >> [..]
> >> After thinking about this, I think these aren't really problems, just
> >> acceptable limitations:
> >
> > I know that these are problems and provided references to proof that in
> > my last email from the xml digital signature specification and the
> > canonicalization specification. Please go back to these references and
> > you will understand.
>
> Konrad,
>
> I thought I understood your points, which I tried to summarize:
>   - client-side transforms do not always result in parseable XML
>   - even when they do, this XML may not be amenable to additional
> server-side transforms due to missing context
>
> Is this a reasonable statement of your points?
>
> My point is this:  These issues require clarification in the core, but I
> think the following would be sufficient:
>   - If the transform results are not XML, send them in <Base64Data>.
> The server should not assume <Base64Data> has any particular form unless
> the profile has mandated it.  I.e. by default the server should only
> hash it, not apply transforms.
>   - If the transform results are XML, they should be sent with enough
> namespace context to support canonicalization through Canonical XML.
>   - Profiles which wish to support server-side transforms which require
> additional context, or require Input Documents of a particular form, may
> place additional constraints on <Base64Data> or <XMLData> (e.g.,
> disallow client-side transforms, require XML that matches a particular
> schema, whatever).
>
> These rules would clarify the core while leaving its basic functionality
> intact.  The core would still support client-side transforms in
> conjunction with server-side canonicalization, server-side hashing, and
> a subset of server-side transforms.
>
> Since minimizing changes to the core is good, the above features are
> worthwhile, and the above clarifications are (I believe) sufficient, I
> don't yet see a need for re-dividing responsibilities between core and
> profiles.
>
>
> >
> >> If your client-side transform produces non-XML, then it's obvious you
> >> can't send the result as XML.
> >
> > I think we now agree on this.
> >
> >> But you should still be able to send it as a hash
> >
> > Yes, and we currently do so using <DocumentHash> and it is implied that
> > all transforms have been done by the client.
> > This is possible with the currently drafted version.
> >
> >> or <Base64Data>.
> >
> > Could you please explain, how you'd then parse the non-XML octet stream
> > using an xml parser. It's not possible as it is not XML.
>
> A basic processing server should not do this, it should just hash the
> octet stream.
>
>
> > Hence almost all server-side transforms are ruled out, as the following.
> [...]
> > Hence only server side Hashing or some Encoding Transform with Hashing
> > remains, which could have been done by the client just as well and then
> > sent as <DocumentHash>.
>
> I disagree that client-side hashing is a perfect substitute for
> server-side hashing.  This requires the client to know which hash
> algorithm is acceptable (not an easy thing these days), and contain code
> to implement it.
>
>
> >
> > So the client will have to send a Document. So this means the last
> > client side transform would have to be a canonicalization with the
> > restriction to return a complete stand alone document without further
> > dependencies. So there is not much value then in doing any further
> > processing at the server and you could just as well do the hashing at
> > the client.
>
> Again, I believe that having the client apply transforms but the server
> apply the hash algorithm has value in certain circumstances.
>
> (Ditto for having the server apply transforms, canonicalization, and
> hashing in the XML case.)
>
>
> >
> >> If your client-side transform is incompatible with certain server-side
> >> transforms, then the server can't apply those transforms.
> >
> > Incompatible here would mean not to send a complete independent xml
> > document.
> >
> >>   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.
> >
> > If you want client-side and server-side transforms for the same
> > ds:Reference at the same time, this should be done by an optional input
> > in a Profile.
> >
> >> [...]
> >>
> >> 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,
> >
> > Yes, it would.
> >
> >> and moving the functionality currently described in
> >> <SignaturePlacement> and <EnvelopingSignature> into core basic
> processing,
> >
> > No it wouldn't.
>
> If the server is going to splice the signature into an XML document, it
> needs to know which document and where to splice, doesn't it?
>
> If the server is going to splice documents into an XML signature, it
> needs to know which documents, doesn't it?
>
> So clearly you're proposing adding some sort of additional functionality
> to basic processing, with some additional guidance provided by the client?
>
>
> >
> >> while adding an optional inputs that requests returning an "unspliced
> >> signature" instead of the spliced one.
> >
> > Yes it would, and could also be done in a profile. Explicit
> requirements
> > of how this splicing would have to be done and how to overcome problems
> > appearing when splicing has to be done by the client could be discussed
> > there extensively.
>
> Okay, but I'd like to first understand what these problems are, and what
> the discussion is going to look like, before we decide where to put it.
>
>
> >
> > This is not as much of a problem with <DocumentHash> and same-document
> > references as the client will exactly know each and every character and
> > every bit, that it has dereferenced, parsed, how it was parsed (ref.
> > datatype normalization, validation), transformed, canonicalized
> and hashed.
>
> If this feature works fine for <DocumentHash>, then we should at least
> leave it in subject to this qualification.
>
>
> >
> >> 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.
> >
> > Exactly, as we have no guarantee that, parsing was done in the
> same way,
> > namespace declarations will still be in the same place etc.. .
> >
> >> 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.
> >
> > Exactly.
> >
> [...]
> >
> >> 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?
> >> [...]
> >
> > It's a problem with client and server parsing, depends
> > presence/absence/difference of schemas and will behave differently in
> > most combination and should be discussed extensively. Again,
> there would
> > be enough room for this in a profile to keep the core slim.
>
> Could you explain in detail, with some examples?
>
> Maybe I'm just naive, but it disturbs me to imagine the server operating
> on a different XML document than the client sent, without this
> difference being represented in the transform chain.
>
> Put another way: this seems like a bigger issue than just 3.3.2 and
> 3.3.3, and I'd like to understand it, to see what other ramifications it
> has on the core, such as Security Considerations.
>
>
> 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
>
>
>