[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] FW: Way forward on issues
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: 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.[...] (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 signaturesCore only supports transformations done at server end. Handling enveloping for other use cases may be defined in future profiles. However this makes things more complicated. To keep things simple I'd advocate for b) only and suggest to move a) to a "client-side transforms profile".- Namespace inheritanceThe 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. 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. What about "ancestry context free XML (no encoding)" or Base64 or Escaped XML for XMLData.2.1 XMLData encoding issueThe core defines use of base64 for encoding binary documents, and use of either: Escaped XML or Base64 for XMLData These are valuable points for a potential "client-side transforms profile".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 also valuable points for a potential "client-side transforms profile", in the core only the following would have to remain:2.2 Exclusive canonicalisationBy 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. The server extracts the XML document from the DSS protocol envelope, without taking inherited namespaces and attributes. I hope from the schema attached to my last email and in previous emails2.3 Unique Particle attributionUse solution 1 in comments tracking document (This is in line with XMLDSig) (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##--- Not having to deal with client side transforms also implies that this stays rather simple.2.4 Ambiguity in section 3.5.8Provide text describing enveloping in line with decision above under enveloping 2.5 XPath expression's commentUpdate as proposed by Konrad (see line 205 of comments document)2.9 Document vs. Signature ValidationNo change to the core. A simplified subset of the core may be defined in future profile(s). best regards Konrad |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]