[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Core spec: client-side transforms, etc.
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]