[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Core spec: client-side transforms, etc.
This is getting difficult to follow as I'm sure it will be for implementers who will ultimately determine its success. Are we saying that any client-side transforms should be accompanied by a new OptionalInput itemizing transforms applied ? What are the constraints that must be followed ? ... or ... Are we saying that specific definition and rules of engagement for this new OptionalInput should be relegated to the profiles ? Is this our general response to simplification of the Basic Processing text ? Would it be possible to crisply/tersely define the suggested changes ? Ed -----Original Message----- From: Konrad Lanz [mailto:Konrad.Lanz@labs.cio.gv.at] Sent: August 1, 2005 12:05 PM To: Nick Pope Cc: Trevor Perrin; Konrad Lanz; dss@lists.oasis-open.org Subject: Re: [dss] Core spec: client-side transforms, etc. Dear Nick and Trevor, please see inline comments. best regards Konrad Nick Pope wrote: >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. > > This is possible and the attribute could be an attribute of Base64Data, but I'm not sure if Base64Data is the right place to indicate this as we'd loose the clear separation between what is/was an xml document and what is a binary document. Also to be able to form a <ds:Reference> the server needs information about the <ds:Transforms> applied. Hence may I suggest that we allow this in combination with an optional input, to only have a small change to the core. Alternatively we could also seperate InlineXML, EscapedXML, Base64XML from DocumentHash and Base64Data by using different BaseTypes. InlineXML, EscapedXML, Base64XML: cannot support client-side transforms. DocumentHash: everything is done by the client. Base64Data: everything, but hashing is done by the client. The latter two require ds:Transforms to be communicated. >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. > > >[...] > > >>From: Trevor Perrin [mailto:trevp@trevp.net] [...] Konrad Lanz wrote: >> >> >>>[...] >>>Trevor Perrin wrote: >>> >>> >>>>1) Client-side transforms >>>>[..] >>>>After thinking about this, I think these aren't really problems, >>>>just acceptable limitations: >>>> >>>> >>>[...]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. >>> >>> >>[...] 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 >> >> - canonicalization requires NodeSetData or parseable XML as input (i.e. a document) - most Transforms require NodeSetData or parseable XML as input (i.e. a document) >>Is this a reasonable statement of your points? >> >> You missed the two points above. Plus the point that the distinctions you are making below and I have made in the past to fix the issue blow up the core considerably. >>My point is this: These issues require clarification in the core, but >>I think the following would be sufficient: >> >> p ... clientside parsing p' ... sever side parsing ser ... client side serialization (Note that ser is not defined for NodeSets) canon ... canonicalization f ... client-side transforms f' ... server-side transforms No, they are not due to the fact that one can produce arbitrary complex NodeSetData x depending on the input document doc x (doc) = f( p( doc ) ) ) using client side transforms f, which will have to be serialized to doc' = ser( x ) and then parsed again at the server side into NodeSetData x'. x' (doc') = p'( doc' ) = p'( ser( x ) ) . Resulting in an effective Transform calculating server side transforms f' and a hash h producing the value hv = h( canon ( f'( p'( ser( f( p( doc ) ) ) ) ) ). Hence hv is only unambiguous for xml parsers p, p', serializations ser and client side transforms f creating intermediate NodeSets x, x' derived from and still dependent on the documents doc, doc' respectively, iff you can assure that hv = h( canon ( f'( f( p( doc ) ) ) ) ) i.e. p' == ser^-1 and hence x (doc) == x' (doc') which implies that doc == doc' demonstrating that f does nothing (i.e. no client side transforms are applied). Alternatively ser == canon (client side canonicalization) would also lead to unambiguous results as per [XMLSig] x' loses it's dependency on doc (the previous document) and doc != doc' is then allowed. However this contradicts basic processing as the server must be able to apply transforms if it whishes and the . >> - 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. >> >> see answer to Nick's suggestion above. >> - If the transform results are XML, they should be sent with enough >>namespace context to support canonicalization through Canonical XML. >> >> i.e. a parsable xml Document, as canonicalization requires NodeSetData as input and can only retrieve this NodeSetData which is to be retrieved from a parsable xml Document. >> - Profiles which wish to support server-side transforms which >>require additional context, or require Input Documents of a particular >>form >> e.g. canonicalization is such a server-side transform, and I think we do have to support it. >>[...] >> >> >>These rules would clarify the core >> Not to having to deal with all these issues in a basic processing is a lot clearer from my point of view. A profile (or optional input) allowing client-side transforms provides you with enough room to discuss it extensively. >>while leaving its basic functionality >>intact. >> This was broken in previous versions of the core. >> [...] >> >>> [...] >>> >>>>But you should still be able to send it as [...] >>>> >>>> <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. >> >> That implies that everything, but hashing has been done by the client and the server may not whish in this case to apply additional transforms. Hence the mixed case is ruled out. >>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.) >> >> see suggestion at the top. >>>> [...] >>>> >>>> >>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? >> >> Use: <dss:SignaturePlacement> >>If the server is going to splice documents into an XML signature, it >>needs to know which documents, doesn't it? >> >> Specified in [XMLSig]. >>So clearly you're proposing adding some sort of additional >>functionality to basic processing, with some additional guidance provided by the client? >> >> No, just use your favourit XMLSig Implementation. >>[..] the server operating >>on a different XML document than the client sent, without this >>difference being represented in the transform chain. >> >> Exactly that is the point, and what happens not having the complete Document underneath the NodeSet after transmission. best regards Konrad --------------------------------------------------------------------- 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]