RE: [dss] DSS Public comments

["Pope, Nick" <Nick.Pope@thales-esecurity.com>]

Konrad,

I agree that adding support for SOAP attachment as a way of carrying input
documents is a very good idea.  However, I am concerned about making such a
significant change to the Core at this stage.

May I suggest rather than adding this to the Core we define a profile using
this approach carried in the "ANYType" field (see section 2.4 line 301).
This is already defined specifically for the purpose of providing
extensibility to support other ways of transporting the Input document from
a DSS client to a server.

We can start immediately on the definition of such a profile.

Nick


> -----Original Message-----
> From: Konrad Lanz [mailto:Konrad.Lanz@labs.cio.gv.at]
> Sent: 24 December 2006 11:37
> To: Pope, Nick; DSS TC List
> Subject: Re: [dss] DSS Public comments
> 
> Dear all,
> 
> I have read the proposal about adding optional support for SOAP
> attachments support to the DSS core and I think this is a very good and
> powerful architectural feature and the DSS core could benefit a lot from
> it.
> 
> Pope, Nick wrote:
> > [...] we may wish to discuss C) below some more. [...]
> >
> > C) The use of DSS and SOAP 1.2 attachments.
> > http://lists.oasis-open.org/archives/dss-comment/200612/msg00002.html
> 
> 
> I think it would basically only affect section 6.2 and not harm other
> parts of the core document I would advocate for considering the adoption
> of this proposal in our next meeting.
> 
> The only changes needed to (WD 47) would be:
> 
> * After line 377 add the text:
> 
> <AttachmentReference> [Optional]
> 
>   This contains a reference to an attachment like SOAP attachments or
> similar data containers that may be passed along with the request. For
> details see section 6.2.1
> 
> * Add after line 387 and in the Schema to Document Type the following
> line:
> 
>         <xs:element ref="dss:AttachmentReference"/>
> 
> 
> ---------- That's all so far, the rest is to extend Section 6.2 --------
> ________________________________________________________________________
> 
> * Create a new section 6.2.1 SOAP Attachment Feature and Element
> <AttachmentReference>
> ________________________________________________________________________
> 
> Applications MAY support SOAP 1.2 attachment feature [SOAPAtt] to
> transmit documents in the context of a <SignRequest> or a
> <VerifyRequest> and can take advantage of
> <Document>/<AttachmentReference>.
> 
> AttRefURI
>   SOAP 1.2 attachment feature [SOAPAtt] states that any secondary part
> ("attachment") can be referenced by a URI of any URI scheme.
> AttRefURI refers to such an secondary part ("attachment") as specified
> for the swaRef type from WS-I Attachments Profile [WS-I-Att], where the
> URI value must resolve within the MIME package. All parts must be made
> available and the encapsulation mechanism is MIME. (cf.
> http://www.ws-i.org/Profiles/AttachmentsProfile-
> 1.0.html#Referencing_Attachments_from_the_SOAP_Envelope)
> 
> <ds:DigestMethod> [Optional Sequence]
> <ds:DigestValue>
>   These optional elements can be used to ensure attachment integrity
> when using WSS, for example.  If these elements are supplied the server
> MUST attach a message digest using the algorithm given in
> <ds:DigestMethod> to the octet stream.
> A digest value is computed when the data is read. After
> the last byte being read from the attachment the server compares the
> calculated digest value against the supplied <ds:DigestValue>. If the
> comparison fails then a RequesterError qualified by a
> GeneralError and an appropriate message containing the AttRefURI is
> returned.
> 
> <xs:element name="AttachmentReference"
> type="dss:AttachmentReferenceType"/>
> <xs:complexType name="AttachmentReferenceType">
>     <xs:complexType name="AttachmentReferenceType">
>         <xs:sequence minOccurs="0">
>             <xs:element ref="ds:DigestMethod"/>
>             <xs:element ref="ds:DigestValue"/>
>         </xs:sequence>
>         <xs:attribute name="AttRefURI" type="xs:anyURI"/>
>     </xs:complexType>
>   <xs:attribute name="AttRefURI" type="xs:anyURI" />
> </xs:complexType>
> 
> * and add the element and type above to the schema.
> ________________________________________________________________________
> 
> * Create a new section 6.2.1.1 Signing Protocol, Processing for XML
> Signatures, Process Variant for <AttachmentReference>
> ________________________________________________________________________
> 
> In the case of an input document which contains <AttachmentReference>
> the server retrieves the MIME headers from the attachment referred by
> AttRefURI and reads the content's MIME type.
> 
> IF the MIME type indicates that it contains XML continue with processing
> as in section 3.3.1 and Step 1 a is replaced with the following:
> 
>   1.
>       a. The server retrieves the data from the attachment referred by
> AttRefURI as an octet string. This data MUST be a well formed XML
> Document as defined in [XML] section 2.1. If the RefURI attribute
> references within the same input document then the server parses the
> octet stream to NodeSetData (see [XMLDSIG] section 4.3.3.3) before
> proceeding to the next step.
> 
> ELSE continue with processing as in section 3.3.4 and Step 1 a is
> replaced with the following:
> 
>   1.
>       a. The server retrieves the data from the attachment referred by
> AttRefURI as an octet string.
> 
> ________________________________________________________________________
> 
> * Create a new section 6.2.1.2 Verifying Protocol, Processing for XML
> Signatures, Process Variant for <AttachmentReference>
> ________________________________________________________________________
> Perform section 4.3. Basic Processing for XML Signatures amending step 2
> a. as follows:
> 
>   2.
>       a. If the input document is a <Document>, the server extracts and
> decodes as described in 3.3.1 Step 1.a (or equivalent step in variants
> of the basic process as defined in 3.3.2 onwards depending of the form
> of the input document) or in the case of <AttachmentReference> as
> described in section 6.2.1.1.
> ________________________________________________________________________
> 
> * Create a new section 6.2.1.3 Signing Protocol, Basic Processing for
> CMS Signatures, Process Variant for <AttachmentReference>
> ________________________________________________________________________
>    Perform section 3.4 Basic Processing for CMS Signatures adding the
> following variant 1. d' after 1. d. and before q. e.:
> 1.
>     d'. If the <Document> contains <AttachmentReference>, the server
> retrieves the data from the attachment referred by AttRefURI as an octet
> string.
> ________________________________________________________________________
> 
> * Create a new section 6.2.1.4 Verifying Protocol, Basic Processing for
> CMS Signatures, Process Variant for <AttachmentReference>
> ________________________________________________________________________
>   Perform section 4.4 Basic Processing for CMS Signatures amending step
> 2 as follows:
> 
> 2. The server retrieves the input data. (In the case of
> <AttachmentReference> this is done as in section 6.2.1.3 step 1. d'.
> If the CMS signature is detached, there must be a single input document:
> i.e. a single <Document> or <DocumentHash> element. Otherwise, if the
> CMS signature is enveloping, it contains its own input data and there
> MUST NOT be any input documents present.
> 
> * add a Reference: [SOAPAtt] http://www.w3.org/TR/soap12-af/
> * add a Reference: [WS-I-Att]
> http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html
> 
> > Happy Christmas to everyone!
> 
> Merry Christmas and Happy Holidays.
> 
> Konrad


This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
You must not disclose, copy or rely on any part of this correspondence if
you are not the intended recipient. 
If you have received this email in error, please delete it from your system
and notify the System Administrator at Thales e-Security +44 (0)1844 201800
or mail postmaster@thales-esecurity.com