Re: [dss] DSS Public comments]

[Stefan Drees <stefan@drees.name>]

Nick,
> As indicated by Konrad we have discussed and come to a conclusion on the
> changes to support SOAP.
> 
> Can you produce a revised version of the Core so that it can be ready for
> final checking and then agreement at the DSS call next monday.

Yes. Thanks a bunch to all contributors!

> There are also the following minor corrections to be made:
> 
> 1) Update the note in 4.3.1 as in comment from Detlef Huehnlein,
> 
> 2) Coorect the schema file (and if necessary the Core spec) with the schema
> change identified in the recent thread "Schema wd47"

Yes. Will do.

> Thanks
You're welcome.

Stefan
> 
> Nick
> 
> -----Original Message-----
> From: Konrad Lanz
> To: DSS TC List; Stefan Drees
> Cc: Juan Carlos Cruellas; Clemens Orthacker
> Sent: 1/15/2007 5:24 PM
> Subject: Re: [dss] DSS Public comments]
> 
> Dear Stefan,
> Dear all,
> 
> Juan Carlos, Nick and myself agreed on the final text changes for 
> dss:AttachmentReference. (Please find below)
> 
> Many thanks to Clemens Orthacker for mayor contributions to the final 
> text proposal for dss:AttachmentReference related parts of the core 
> document.
> 
> regards
> Konrad
> 
> P.S: There is a broken cross reference in line 907.
> 
> Juan Carlos wrote:
>> [...] one very minor editorial change intermixed. My view is
>> that the best way we could proceed is that you fix it, sends the
> message
>> to the list and Nick gives the OK to Stefan so that he may include.
> [...]
> The only changes needed to (WD 48) 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") and MUST
>   resolve within the compound SOAP message. The default encapsulation
>   mechanism is MIME as specified in the WS-I Attachments
>   Profile [WS-I-Att] (cf. swaRef,
> 
> http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html#Referencing_Att
> achments_from_the_SOAP_Envelope). 
> 
> 
> MimeType [Optional]
>   Declares the MIME type of the referred secondary part of this SOAP
>   compound message.
> 
>   Note: If MIME is used as encapsulation mechanism, the MIME
>   content-type is available via a MIME header. However, the MIME
>   headers may not be available to implementions and the SOAP 1.2
>   attachment feature is not restricted to MIME. Further the MIME
>   header is not secured by the AttachmentReference's DigestValue,
>   which is calculated over the binary attachment data (not including
>   the MIME headers).
> 
> <ds:DigestMethod> [Optional Sequence]
> <ds:DigestValue>
>   These optional elements can be used to ensure the integrity of the
>   attachment data.
> 
>   If these elements are supplied the server SHOULD compute a message
> digest
>   using the algorithm given in <ds:DigestMethod> over the binary data in
>   the octet stream and compares it against the supplied
> 
> JC wrote:
>> 1. ------->JC: "the server SHOULD compute (...) and compare", not 
>> "compares" as reads here
> 
> Konrad writes:
>> Stefan please remove the s from compares
> 
> 
> <ds:DigestValue>.
>   If the comparison fails then a RequesterError qualified by a
>   GeneralError and an appropriate message containing the AttRefURI is
>   returned.
> 
> Note: The attachments digest value(s) can be included in the primary
> SOAP part to allow the entire request (including secondary parts) to be
> secured by WSS. However, the MIME headers are not covered by the
> digest value and therefore can be included into the
> dss:AttachmentReference (which is relevant for the processing of
> dss:IncludeObject referring to an dss:AttachmentReference).
> The digest value may be computed while the data is read from the
> attachment. After the last byte being read from the attachment the
> server compares the calculated digest value against the supplied
> <ds:DigestValue>.
> 
> 
> <xs:element name="AttachmentReference"
> type="dss: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:attribute name="MimeType" type="xs:string" use="optional"/>
> </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 type from the MimeType attribute (if present)
> otherwise from the content-type MIME header of the attachment referred
> by
> AttRefURI. If the MimeType attribute diverges from the attachment's
> MIME header content-type, an implementation MAY either ignore the MIME
> header's content-type or issue a RequesterError qualified by a
> GeneralError and an appropriate message containing the AttRefURI.
> 
> 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 stream. 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 stream.
> 
> Note: In the first case attachmentReference is always treated like
> Base64XML in the latter like Base64Data for further
> processing. (e.g. In the case of dss:IncludeObject, the MimeType
> attribute is copied from dss:AttachmentReference to ds:Object.)
> 
> ________________________________________________________________________
> 
> * 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
> stream.
> ________________________________________________________________________
> 
> * 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
> 
> Konrad Lanz escribió:
>> Dear Juan Carlos,
>>
>> I addressed everything we bespoke in the skype call and had a quick 
>> email exchange with Clemens, please see below.
>>
>> I'll post this to the list as soon as I hear from you.
>>
>> regards
>> Konrad
> 
>