FW: [dss] FW: Way forward on issues

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

Following the additional comments from Konrad Lanz in his email:

http://www.oasis-open.org/apps/org/workgroup/dss/email/archives/200506/msg00
019.html

Juan Carlos, Stefan, Konrad and I had a call to identify the best way
forward and as a result proposed the following update to the proposal that
was discussed on Monday.

I believe that in general his suggestions simplifies the use of the Core,
avoids potential complexities with transforms and corrects some addition
issues on the "Unique Particle attribution" issue.

I therefore to propose that Stefan uses this as the basis of producing the
new working draft of the Core, unless any further major objections are
raised.

Nick

> -----Original Message-----
> From: Nick Pope [mailto:pope@secstan.com]
> Sent: 10 June 2005 17:01
> To: OASIS DSS TC
> Subject: [dss] FW: Way forward on issues
>
>
> Dear All,
>
> Our objective is top clear off all the issues as much as possible at
> Monday's conference call, and by the end of next week at the
> latest so that
> Stefan call produce a revised Core for completion in July.  In
> order to meet
> this objective Stefan, Juan Carlos and I consider the following
> resolutions
> best respresent the current consensus on the outstanding issues.
>
> Nick
>
> (Note see also Comments document:
> http://www.oasis-open.org/apps/org/workgroup/dss/download.php/1264
> 1/oasis-ds
> s-1.0-comments-track-wd-02-dl-20050515.doc
> )
>
> > - Enveloping signatures
>
> Core only supports transformations done at server end.  Handling
> enveloping
> for other use cases may be defined in future profiles.
>

Similar complications arrise with Enveloped signatures so the same
limitation applies to enveloped signatures.

> > - Namespace inheritance
>
> The core supports use cases where either:
> a) all transformations required fopr signature, including
> canonicalization,
> are done at the client end,
> b) all transformations required for the signature are applied at
> the server
> end.
>

On discussing the other possible uses of cases where the client performs
transforms, the only case where the client transormation seems to make sense
is where the client send the document hash instead of the document (e.g. as
in Entity Seal profile).

So it is proposed to only support client transforms in the core with
document hash.  There are difficulties in a number of situations if client
transforms are to employed so some guidance notes is to be included warning
of certain situations to be avoided in case profiles do employ transforms.

> Future profiles may define procedures for other use cases for some
> transformations done in the client and some in the server.
>
> > 2.1 XMLData encoding issue
>
> The core defines use of base64 for encoding binary documents, and use of
> either:
>     Escaped XML or Base64 for XMLData
>
> Note: In the situation where the client applies transformations, including
> Canonicalization, to XML then it is recommended that Base64 is used,
> otherwise Escaped XML should be used.
>

The existing "ancestry context free XML (no encoding)" is also to be
included.

>
> > 2.2 Exclusive canonicalisation
>
> By default where server is not applying transforms other than "normal"
> canonicalization then after extracting the XML document from the DSS
> protocol envelope, without taking inherited namespaces and attributes,
> standard (c14n) canicalization is applied.  In situations where the server
> is applying other transforms then the server shall apply the appropriate
> form of canonicalization and indicate the transforms applied, including
> canonicalization if necessary, in the DS:SignedInfo.
>
Further clarifying this point:
The server extracts the XML document from the DSS protocol envelope, without
taking
inherited namespaces and attributes.


> > 2.3 Unique Particle attribution
>
> Use solution 1 in comments tracking document (This is in line
> with XMLDSig)

Konrad ideitified a problem with this solution.  The variation suggested by
Konrad was considered by it is proposed to go for the Solution 2 (ANY type)
which is closest to the current approach and has least impact on the Interop
tests.

>
> > 2.4 Ambiguity in section 3.5.8
>
> Provide text describing enveloping in line with decision above under
> enveloping
>
> > 2.5 XPath expression's comment
>
> Update as proposed by Konrad (see line 205 of comments document)
>
> > 2.9 Document vs. Signature Validation
>
> No change to the core.  A simplified subset of the core may be defined in
> future profile(s).
>
>

A further point was raised in that the document carried between <XMLData>
tags should be a complete documents and certain restrictions should be
placed to avoid complexities.

>
>
> ---------------------------------------------------------------------
> 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
>
>
>