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: Proposal for restructured basic processing.


Stefan Drees wrote:
> Dear all,
> 
> here it is, our proposal for the new and shiny 3.3:
well with minor modifications and corrections at the bottom of this 
posting the freshest 3.3.

Details:
* (corrected 1.c.iii, 1.c.iv and 3 as compared to previous
    posting)
* plans are to incorporate the processing of a
   <DocumentHash> along the lines of:
	1. For each <DocumentHash> in ... continue with 1.c
* hopefully the basic processing now fulfills the twofold promise
   given by the notions of "basic" as both "simple" *and* "reusable
   Groundwork".
* please note, that we now have a compromise between a clean object
   tree (<Document> now having type advertising elements <Base64XML>,
   ...) instead of the former (not really working) dispatching attribute
  (encoding) and the minimalistic schema (minimum elements).

   **but**

   it would also be possible - if necessary to further enable clear and
   concise processing descriptions - to define <InputDocuments> in a way
   as to contain <DocumentHash>, <Base64Document>, <EscapedXMLDocument>,
   <InlineXMLDocument> and <Base64Data>.

Please note (sorry, private reasons):
- Although I will not be available for telco this afternoon, it would
   be very helpful for keeping the current pace, if a short telco,
   probably via skype would be possible with the participation
   of Nick, Trevor and Konrad as to give some consolidated feedback to
   the current route to follow.
   Konrad was so nice, to share his phone number via the dss-roster, so
   he is available via skype *and* via normal phoning around 1700 CEST.

"""
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 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:
a.	In the case of <Base64XML>, the server base64-decodes the document 
[XML-NT-Document] contained in <Document> into an octet stream.
i.	Processing continues with step b for an external RefURI.
ii.	For a same-document ReferenceURI [XMLSig-Same-Document] the server 
tries to parse the octet stream to NodeSetData [XMLSig-Node-Set-Data].
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].
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. 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.





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