Re: [dss] DSS Public comments

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

Hi JC,

JC wrote:
 > I feel a bit uneasy,

No need, all questions answered.

comments intermixed, example at the end.

Konrad

Juan Carlos Cruellas wrote:
> [...] Clemens' proposal would introduce some kind of duplicity, in 
> which case we could increment the risks of incoherences in some request.

No it doesn't as Clemens wrote:

> 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. 

Note the (if present) otherwise, and this is only to distinguish
between xml and non xml.

If someone explicitly needs the MIME Type set in a <ds:Object> he will
always have to provide it in the AttachmentReference, as this goes into
the signature.

Juan Carlos wrote:
> [...] would it be acceptable to put this text in an informative annex 
> of the core [...]

I disagree.

> I think it would be better to use "include the message digest value"  
> and leave "attach" for actual attachments. [...]

The intention is that the server shall retrieve the binary data from the
attachment as a stream and compute the digest in a streaming way, on the
fly.

However instead of mandating this (which is an implementation detail of
this optional section) we could say:
"""
If these elements are supplied the server MUST 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 <ds:DigestValue>.
If the comparison fails then a RequesterError qualified by a
GeneralError and an appropriate message containing the AttRefURI is
returned.
"""

And add a Note.

Note: 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>.

> The text does not say what happens If the RefURI attribute references 
> outside the same input document... need of completion.

Not true,
as Konrad wrote:
> 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.

Maybe we change "URI value MUST resolve within the MIME package".
must --> MUST .

Even better (more general) would be to say
"""
AttRefURI refers to such an secondary part ("attachment") and MUST 
resolve within the compound SOAP message. The default encapsulation 
mechanism is MIME as specified for the swaRef type from WS-I Attachments 
Profile [WS-I-Att].
"""

So I suggest the latter.

Juan Carlos wrote:
> ---> So, in summary, if the contents of the attachement are xml then 
> we check well-formedness, and if required, parse it.

Yes, we would just treat it just like <dss:Base64XML>.

> [...] I guess that your assumption is that this would not have any 
> impact on the processing, wouldn't it Konrad? 

True.

> --> If no xml content, then just read the charater as it is and hash 
> it...but Konrad's text does not say anything about the note in 
> 3.3.4... should it be still applicable here? it explicitly mentions 
> base64...so, my conclusion is that this note does not apply anymore 
> for this...should not text say that?

That's obviously still the same, as you will need to include the data
into your <ds:Object> as base64 (i.e. you encode the stream retrieved
from the attachment and you are ignorant of how it was stored in the
attachment).

BTW. we forgot to mention that a server should set the encoding
attribute of ds:Object (but that's maybe obvious anyway).

>> 2. The server retrieves the input data. [...]
>
> If the CMS signature is detached, there must be a single input document:
> i.e. a single <Document> or <DocumentHash> element. If <Document> 
> contains an <AttachmentReference> element then the server retrieves 
> the input data as in section 6.2.1.3 step 1. d'. If the
> CMS signature is enveloping, it contains its own input data and there
> MUST NOT be any input documents present.

Agreed, says the same and reads much better.

 > [...] Konrad if he could send some simple example of this appearance.

   MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary;
    type=text/xml; start="<request.xml@example.com>"

--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <request.xml@example.org>

<?xml version='1.0' ?>
<s:Envelope xmlns:s='http://www.w3.org/2002/12/soap-envelope' >
    <s:Header>
      <wss:Security xmlns:wss='...' >
      </wss:Security>
    </s:Header>
    <s:Body>
      <dss:Request xmlns:dss='...' >
      ...
      <AttachmentReference attRefURI='http://example.org/example.jpg'
MimeType='image/jpeg'>
         <ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
         <ds:DigestValue>j6lVu8nk=</DigestValue>
      </AttachmentReference>
      ...
      </dss:Request>
    </s:Body>
</s:Envelope>

--MIME_boundary
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-Location: 'http://example.org/example.jpg

fd a5 8a 29 aa 46 1b 24

--MIME_boundary

--- Begin Message ---

• From: Juan Carlos Cruellas <cruellas@ac.upc.edu>
• Date: Fri, 12 Jan 2007 18:12:46 +0100

Dear all,

My comments intermixed as agreed in our last conf call.

First of all, I would like to also comment the remark made by Clemens 
Orthacker.

I agree with his first remark.

He says that: "The second remark is that in order to set the MIME type 
in <ds:Object> elements in the result, it would be advisable to add a 
MimeType attribute to the AttachmentReference type (just as in the 
Base64Data element)[1]."

I am not familiar with SOAP attachments but Konrad in his text mentions 
that:
"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."

So it seems as in the SOAP attachement the MIME type is present, so I am 
not sure whether Clemens' proposal would introduce some kind of 
duplicity, in which case we could increment the risks of incoherences in 
some request.

As for Konrad's text see intermixed below....

I must confess that I haven't had enough time for reading the two 
references that Konrad mentions so I am still uncertain on the specific 
appearance that attachments would have and the values in the referencing 
URIs....I wonder if it would be asking too much to kindly ask Konrad if 
he could send some simple example of this appearance.

I think that Konrad's proposal isolates the processing of the SOAP from 
the rest of the document... but I must confess that, due to the fact 
that I am not familiar with the documents Konrad references I feel a bit 
uneasy, as I have made some comments even my lack of experience 
(although I am not sure they are right ;-)....anyway, this leads me to 
ask, would it be acceptable to put this text in an informative annex of 
the core? implementors could still find material for their 
implementations and we would not have introduced this relevant material 
at the last moment in the normative part....just a (maybe not suitable) 
proposal...

Juan Carlos.

Konrad Lanz escribió:
> 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 

--->JC: I am not sure of the usage of "attach" within the sentence "the 
server MUST attach a message digest.."... If my understanding of what 
Konrad tries to say is correct I think it would be better to use 
"include the message digest value"  and leave "attach" for actual 
attachments.

> <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

Would not be better:
A digest value is computed when the data is read after
the last byte has been read from the attachment. Then the server 
compares the calculated ...."?

> 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>
> 
Agree with Clemens: cut and paste problems.

> * 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.
> 

The text does not say what happens If the RefURI attribute references 
outside the same input document... need of completion.

---> So, in summary, if the contents of the attachement are xml then we 
check well-formedness, and if required, parse it.
Question, I am not aware how many MIME types have been defined for XML 
content... I guess that your assumption is that this would not have any 
impact on the processing, wouldn't it Konrad?

> 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.
> 

--> If no xml content, then just read the charater as it is and hash 
it...but Konrad's text does not say anything about the note in 3.3.4... 
should it be still applicable here? it explicitly mentions base64...so, 
my conclusion is that this note does not apply anymore for this...should 
not text say that?

> ________________________________________________________________________
> 
> * 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.

---> I am not sure I like the sentence. An attachment of the document is 
a special case of a dettached signature, isn't it? so, I think that it 
would be better something like:

If the CMS signature is detached, there must be a single input document:
i.e. a single <Document> or <DocumentHash> element. If <Document> 
contains an <AttachmentReference> element then the server retrieves the 
input data as in section 6.2.1.3 step 1. d'. 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
> 

--- End Message ---