RE: [dss] DSS Public comments]

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

Stefan,

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.

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"

Thanks

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


-- 
Konrad Lanz, IAIK/SIC - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Tel: +43 316 873 5547
Fax: +43 316 873 5520
https://www.iaik.tugraz.at/aboutus/people/lanz
http://jce.iaik.tugraz.at

Certificate chain (including the EuroPKI root certificate):
https://europki.iaik.at/ca/europki-at/cert_download.htm

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