Re: [dss] DSS Public comments

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

Hi Nick,

my preference is to put this into section "6.2 SOAP 1.2 Transport 
Binding" as the changes basically only affect this section - which 
otherwise would be rather thin.

Pope, Nick wrote:
> I agree that adding support for SOAP attachment as a way of carrying input
> documents is a very good idea.  [...]
It is a crucial feature to enable DSS implementations to sign large 
files without having all the overhead of carrying large binary documents 
through the parsers/serializers and base64 encoding/decoding. Also, this 
indirection mechanism should be very useful for profiles as well.
> We can start immediately on the definition of such a profile.
>   
I don't think it is a large enough problem/chunk to really require a 
separate profile/document and it doesn't disturb other parts of the core.

regards
Konrad

PS.: In java for instance the size of dss request congaing a 50 
Megabytes binary document would increase by 33% for base64 encoding and 
multiplied by 2 for the internal utf16 representation which results in 
133 Megabytes in memory and thats a conservative estimate as we'd need 
to add linebreaks as well every 76 characters. Attachments on the other 
hand could be used binary as they are and streamed easier.

largeBinaryDoc ->
clientBase64encode ->
put into a node ->
serialize ->
transmit to Server ->
serverParse ->
serverBase64decode

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