Re: [dss] DSS Public comments

[Konrad Lanz <Konrad.Lanz@labs.cio.gv.at>]

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