Re: [dss] FW: Way forward on issues

[Konrad Lanz <Konrad.Lanz@labs.cio.gv.at>]

Dear All,

sorry for commenting on this a bit late, but I hope many points could be seen from my previous emails already.
If not I'd once again like to point them out and add a few others. Sorry to be lengthy but I think it's worth the effort as a lot of points are discussed in one posting.

please see below

Nick Pope wrote:

[...]
(Note see also Comments document:
http://www.oasis-open.org/apps/org/workgroup/dss/download.php/12641/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.
  

We'd also have to restrict that if a request leads to an enveloped signature the input document pointed to by dss:SignaturePlacemement is not allowed to have client-side transforms, the server would have to place the ds:Signature into the original document.
However this makes things more complicated.

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

Future profiles may define procedures for other use cases for some
transformations done in the client and some in the server.
  

To keep things simple I'd advocate for b) only and suggest to move a) to a "client-side transforms profile".
I would add an optional Input to the "client-side transforms profile" which is equivalent to input document
but is called <dssctp:IntermediadeTransformationResult> and extends dss:DocumentBaseType.
It is also crucial to move the ds:Transform from dss:DocumentBaseType to dssctp:IntermediadeTransformationResult.
Meaning we should remove ds:Transforms from dss:DocumentBaseType and hence also from the core.
So we'd call it what it really is, and cannot have a content inside <dss:Documnet> any more that potentially is no document after all.

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
  

What about "ancestry context free XML (no encoding)" or Base64 or Escaped XML 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.

(JC - I thought of the use case that would make Base64 encoding of XML a
good idea as above)
  

These are valuable points for a potential "client-side transforms profile".

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.
  

These are also valuable points for a potential "client-side transforms profile", in the core only the following would have to remain:

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)
  

I hope from the schema attached to my last email and in previous emails
(http://lists.oasis-open.org/archives/dss/200504/msg00048.html, http://lists.oasis-open.org/archives/200504/msg00012.html)
I hope one could see that it is important not to forget that also "XMLSignature" and "XMLKeyInfo" have to be introduced to solve the UPA Problem.

This packing of elements from different namespaces further underlines the payload character of ds:Signature and ds:KeyInfo and equal ancestry context free extraction (or opaqueness should be granted) as for dss:XMLData including equal encoding possibilities are required.

If someone comes up with better names than XMLData, XMLSignature, XMLKeyInfo this might also help understanding.
(Probably DocumentFrame, SignatureFrame, KeyInfoFrame or DocumentPayload, SignaturePayload, KeyInfoPayload might be a good idea, but this is not so crucial)

---##BEGIN##--- selected sections for the DSS-Schema ---##BEGIN##---

    <xs:element name="XMLSignature">
        <xs:complexType>
            <xs:sequence>
                <xs:element ref="ds:Signature"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>

    <xs:element name="XMLKeyInfo">
        <xs:complexType>
            <xs:sequence>
                <xs:element ref="ds:KeyInfo"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>

it might be also of advantage to define the following as well

    <xs:group name="ExtensionGroup">
        <xs:sequence>
            <xs:any namespace="##other" processContents="lax"/>
        </xs:sequence>
    </xs:group>

and to use them like that

    <xs:element name="SignatureObject">
        <xs:complexType>
            <xs:sequence>
                <xs:choice>
                    <!--                    <xs:element ref="ds:Signature"/>                -->
                    <xs:element ref="dss:XMLSignature"/>
                    <xs:element ref="dss:Timestamp"/>
                    <xs:element ref="dss:Base64Signature"/>
                    <xs:element ref="dss:SignaturePtr"/>
                    <xs:group ref="dss:ExtensionGroup"/>
                </xs:choice>
                <xs:element name="Schema" type="xs:base64Binary" minOccurs="0"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>

                <xs:element name="KeySelector">
                    <xs:complexType>
                        <xs:choice>
                            <!-- <xs:element ref="ds:KeyInfo"/> -->
                            <xs:element ref="dss:XMLKeyInfo"/>
                            <xs:group ref="dss:ExtensionGroup"/>
                        </xs:choice>
                    </xs:complexType>
                </xs:element>

    <xs:element name="Timestamp">
        <xs:complexType>
            <xs:choice>
                <!--                <xs:element ref="ds:Signature"/> -->
                <xs:element ref="dss:XMLSignature"/>
                <xs:element name="RFC3161TimeStampToken" type="xs:base64Binary"/>
                <xs:group ref="dss:ExtensionGroup"/>
            </xs:choice>
        </xs:complexType>
    </xs:element>

---##END##--- selected sections for the DSS-Schema ---##END##---

2.4 Ambiguity in section 3.5.8
    

Provide text describing enveloping in line with decision above under
enveloping
  

Not having to deal with client side transforms also implies that this stays rather simple.

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

best regards

Konrad