Re: [dss] suggestion for 3.3.3 (Action 05-07-25-1)

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

Hi Juan Carlos,

Juan Carlos Cruellas wrote:

> [...] the whole purpose of the "SignaturePlacement"
> element is to instruct the server to actually insert the signature
> within one of the documents sent by the client.

I agree, but I'm not so sure that this also implies that the document 
which gets the signature placed inside
should under any circumstance be referenced by a ds:Reference having an 
EnvelopedSignatureTransform.
In the default case I agree that this is typical and hence we set 
default="true" on this attribute.

> What is the justification for
> this attribute.... 

To have clarity about what the client really wants.

> What would you expect the server's behaviour should be
> if the value for this attribute was "false"...not inserting the signature
> in the document?

No as, it would mean to insert the signature in to the document, but not 
to reference it and hence not to sign it at all or via 
<dss:SignedReference> RefURI attribute.
This means you could for instance insert a signature into a Document and 
reference parts of it by ds:SignedReferences. E.g.:

<Document>
  <Element1>
  ... sign this Part ...
  </Element1>
  <Element2>
  ... sign this Part ...
  </Element2>
  ... Do not sign anything else ...
  <Element3>
  ... not signed ...
  </Element3>
  <Signature ID? xmlns="http://www.w3.org/2000/09/xmldsig#";> 
     <SignedInfo>
       <CanonicalizationMethod/>
       <SignatureMethod/>
       <Reference URI="#xpointer(/Document/Element1)" >
         <Transforms>
         <DigestMethod>
         <DigestValue>
       </Reference>
       <Reference URI="#xpointer(/Document/Element2)" >
         <Transforms>
         <DigestMethod>
         <DigestValue>
       </Reference>
     </SignedInfo>
     <SignatureValue> 
    <KeyInfo>
    <Object ID?>
   </Signature>
  ... not signed ...
</Document>

You could achieve the same effect by using an EnvelopedSignature and 
Transform XPath-Filters 2.0 as well, however this is just an example.

If the same request would also have "createEnvelopedSignature" set to 
true everything but the SignedInfo (which cannot be signed recursively) 
would be hashed together via a third ds:Reference having an 
EnvelopedSignatureTransform. Element1 and Element2 would then be double 
hashed in a way. 

> if, as you mention in one of your emails, we allow splicing
> by clients (with all the restrictions and notes you mention), then, 
> asuming
> that you would have in one document a same-document URI, the server 
> should imagine
> that the client would splice the signature within the document...

I'm sorry, but I'm not sure if I understand this question right.
Can you please try to put it in another way and refer to the email and 
the relevant section in question.
Thanks a lot.

> [...]
> Konrad Lanz wrote:
>
>> [...]
>>        <xs:element name="SignaturePlacement">
>>            <xs:complexType>
>>                <xs:choice>
>>                    <xs:element name="XPathAfter" type="xs:string"/>
>>                    <xs:element name="XPathFirstChildOf" 
>> type="xs:string"/>
>>                </xs:choice>
>>                <xs:attribute name="WhichDocument" type="xs:IDREF"/>
>>                <xs:attribute name="createEnvelopedSignature" 
>> type="xs:boolean" default="true"/>
>>            </xs:complexType>
>>        </xs:element>
>>
>> The server splices the Signature into the Document and returns it as 
>> DocumentWithSignature:
>>
>> Further if createEnvelopedSignature == true do Basic Processing and 
>> override Step 4. to include an  Enveloped Signature Transform as the 
>> first Transform.
>> An EnvelopedSignature signature is a Signature enveloped in a 
>> document pointed at by the same-document URI="".
>> Hence the <dss:Document> pointed at by Which Document must have no or 
>> the empty URI="" as a value for RefURI and must be parseable xml.
>
best regards
Konrad