OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dss] suggestion for 3.3.2 (Action 05-07-25-1)



A small point,

But no other optional inputs are part of basic processing.

For consistency I suggest either:
  a) making this a typical optional input, i.e. not part of basic processing
  b) making this a fundamental part of the protocol, i.e. not an 
optional input

Since you intend profiles to choose it or not, I suggest (a).


I also suggest not deleting the current text about client-side splicing, 
but adding qualifications (e.g., that it can be used for <DocumentHash>, 
or with servers that do not normalize inputs).


Trevor


Konrad Lanz wrote:
> Dear all,
> 
> The problem with the current text is that client side splicing could 
> potentially lead to signatures not validating due to problems with 
> normalization and lost/inherited namespaces plus that the name 
> Enveloping signature does not reflect the fact that multiple such 
> objects can be included in a signature.
> 
> An EnvelopingSignature is a Signature having <ds:Objects> which are 
> referenced by <ds:References> having a same-document Uri.
> 
> Hence an <dss:Document> having a same-document Uri and an optional input 
> pointing at it is to be inserted as an <ds:Object> included/spliced in 
> the signature and returns the signature.
> 
> The suggestion concerning EnvelopingSignature is to rename the optional 
> Input <dss:EnvelopingSignature> to <dss:IncludeObject> and modify it as 
> follows to replace current Section 3.3.1.
>        <xs:element name="IncludeObject">
>            <xs:complexType>
>                <xs:attribute name="WhichDocument" type="xs:IDREF"/>
>                <xs:attribute name="hasObjectTagsAndAttributesSet" 
> type="xs:boolean" default="false"/>
>                <xs:attribute name="ObjId" type="xs:string" use="optional"/>
>            </xs:complexType>
>        </xs:element>
> 
> And add the following normative text:
> 
> The server splices the to-be-enveloped documents as <ds:Object>(s) into 
> the returned <ds:Signature>. (This step might be omitted in a Profile)
> A client can use any server that implements basic processing to create 
> an enveloping XML signature by using this optional input.
> To do this, the client refers to this object using a same-document URI 
> value for the RefURI attribute of the Document pointed at by WhichDocument.
>    The given URI should dereference the relevant parts of the included 
> Object to be included in the calculation for the corresponding reference.
> 
> In the case of the Document pointed at by WhichDocument having 
> Base64Data, <ds:Object>('s) MIME Type is to be set to the value of 
> <dss:Base64Data>('s) MIME Type value and the Encoding is to be set to 
> http://www.w3.org/TR/xmlschema-2/#base64Binary.
> 
> 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]