RE: [dss] Re: Proposal for restructured basic processing.

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

Stefan, Konrad,

This is a better.

I propose the following word changes to make the process even clearer.

I am around Friday AM.  Can we discuss this via Skype. Any particular time?

Nick


> 3.3 1.1 Basic Processing for XML Signatures
> A DSS server that produces XML signatures SHOULD perform the following
> steps, upon receiving a <SignRequest>.
> These steps may be changed or overridden by

I suggest add:
"procedures defined for "

> the optional inputs (for
> example, see section 3.5.5), or by the profile or policy the server is
> operating under.
> The ordering of the <Document> elements inside the <InputDocuments> MAY
> be ignored by the server.
> 1.	For each <Document> in <InputDocuments> not referenced by optional
> inputs the server MUST perform the following steps:

?? "Not Referenced by Optional Inputs"

What optional inputs?  Is this necessary given the statement that the steps
may be overridden by the specific optional inputs?

> a.	In the case of <Base64XML>, the server base64-decodes the
replace
> document contained in <Document> into an octet stream.

with
"the data contained within <Document> into an octet string.
This data MUST be a well formed XML Document as defined in clause 2.1
of [Schema1]. "

> i.	Processing continues with step b for an external RefURI.
> ii.	For a same-document ReferenceURI
replace
> [XMLSig-Same-Document]
with
(see clause ?? of  [XMLSig])

> the server
Replace
> tries to parse
?? Why tries to parse.  If the document is well formed then it should parse.

"parses"

> the octet stream to NodeSetData
replace
>[XMLSig-Node-Set-Data].
with
(see clause ?? of [XMLSig])

> b.	The server MAY apply additional XML signature transforms.  These
> transforms should be applied
> as per [XMLSig-RefProcModel] .
> i.	Processing continues with step c for an octet stream.
> ii.	Following [XMLSig], if the end result of these transforms is an XML
> node set, the server must convert the node set back into an octet stream
> using Canonical XML [XML-C14N].

If the data is a node set then there will need to be canonicalization even
if no transforms are to be applied  This is all best done by reference to
[XMLSig].

"b) The data is processed and tranforms applied by the server to produced a
canonicalized octet string as required in clause 4.3.3.2 of [XMLSig].

Note: As required in [XMLSig] if the end result is an XML
 node set, the server MUST attempt to convert the node set back into an
octet stream
 using Canonical XML [XML-C14N]."

-
In addition, regarding Trevors suggestion to allow client transforms, I
suggest that we have an attibute of document that the client uses to
explicetly signal that the data is a canonical octet-string and hence no
transforms are required.



> c.	The server forms a <ds:Reference> with the elements and attributes
> set as follows:
> i.	If the <Document> has a RefURI attribute, the <ds:Reference>
> element’s URI attribute is set to the value of the RefURI attribute,
> else this attribute is omitted.
> A signature MUST NOT be created if more than one RefURI is omitted in
> the set of input documents.
> ii.	If the <Document> has a RefType attribute, the <ds:Reference>
> element’s Type attribute is set to the value of the RefType attribute,
> else this attribute is omitted.
> iii.	The <ds:DigestMethod> element is set to the hash method used.
> iv.	The <ds:DigestValue> element is set to the hash value that is to be
> calculated as per [XMLSig].
> v.	The <ds:Transforms> element is set to the sequence of transforms
> applied by the server in steps 1 and 2.

Now "Steps a & b"


> This sequence MUST describe the
> effective transform as a unique procedure from parsing until hash.
> 2.	References resulting from processing of optional inputs MUST be
> included. In doing so, the server MAY reflect the ordering of the
> <Document> elements.
> 3.	The server creates an XML signature using the
> <ds:Reference> elements
> created in Step 1.c, according to the processing rules in [XMLSig].
> """
>
> All the best,
> Stefan.
>
>
>
>
> ---------------------------------------------------------------------
> 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
>
>
>