Re: In a VerifyRequest we need to disambiguate [Action 06-12-04-03]

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

Hi Stefan,
please include those changes into the core document.

Hi everybody,
please review my proposal.


The changes apply to "oasis-dss-1.0-core-spec-cd-r5.pdf".

* section 2.4.3 Line 403
   <ds:Transforms> [Required on a SignRequest] [Optional on VerifyRequest]

* section 2.4.4 Line 425
   <ds:Transforms> [Required on a SignRequest] [Optional on VerifyRequest]

* Add the following text for the Attribute to sections 2.4.3 and 2.4.4

   WhichReference [Ignored on a SignRequest] [Optional on a VerifyRequest]
     As there may be multiple TransformedData/DocumentHash elements of
the same document having the same URI and RefType on a SignRequest or
VerifyRequest - their correspondance to an already existing
<ds:Reference> however needs to be established on a VerifyRequest only.
There is a need to disambiguate such cases. This Attribute hence offers
a way to clearly identify the <ds:Reference> when URI and RefType match
multiple ds:References/TransformedData/DocumentHash. The corresponding
ds:Reference is indicated by this zero-based WhichReference attribute (0
means the first <ds:Reference> in the signature, 1 means the second, and
so on).

* Add the following after the Attribute to sections 2.4.3 only
   Note: It may be possible to establish the
ds:References/TransformedData/DocumentHash correspondence by comparing
the optionally supplied chain of transforms to those of the
ds:References having the same URI and RefType in the supplied
ds:Signature if this chain of transform has been supplied. This can be
quite expensive and even out the advantages of
TransformedData/DocumentHash.

* Add the following attribute to the schema Fragment of TransformedData
and DocumentHash
   <xs:attribute name="WhichReference" type="xs:integer" use="optional"/>

* Line 429
   <ds:DigestMethod> [Required on a SignRequest] [Optional on VerifyRequest]

* Line 442 and change in the Schema file
   <xs:element ref="ds:DigestMethod" minOccurs="0"/>

* Add the following attribute to the schema Fragment of TransformedData
and DocumentHash
   <xs:attribute name="WhichReference" type="xs:integer" use="optional"/>

* New Text for Section 4.3 point 2. variant b. and c. Lines 1538 - 1544 :

b. If the input document is a <TransformedData>, the server MAY check
that the <ds:Transforms> (if supplied) match between the
<TransformedData> and the <ds:Reference> and then hashes the resultant
data object according to <ds:DigestMethod>, and MUST check that the
result matches the <ds:DigestValue>.

c. If the input document is a <DocumentHash>, the server MAY check that
the <ds:Transforms>, <ds:DigestMethod> (if supplied) and
<ds:DigestValue> elements match between the <DocumentHash> and the
<ds:Reference>.

d. If the combination of RefURI and RefType matches more than one input
document all of them MUST be either a <TransformedData> or  a
<DocumentHash> otherwise a RequesterError is issued qualifyed by result
minor of ReferencedDocumentNotPresent.
Only one of them is allowed to have a WhichReference value that matches
the order of the <ds:Reference> within the <ds:SignedInfo> in question
otherwise a RequesterError is issued qualifyed by result minor of
ReferencedDocumentNotPresent. Using this input document either variant
b. or c. is applied respectively before continuing with step 3.
@@@ maybe we need a better error message here.

kind regards

Konrad

PS.: I noticed that the PDF Version on the dss main page still is a
draft from April 2006 and needs to be updated. The Word document seems
allright tough.


Konrad Lanz wrote:
> Dear all,
>
> In a <dss:VerifyRequest> we need some disambiguation in the case of a 
> request carrying multiple
> <dss:DocumentHash>, <dss:TransformedData> or a combination of those 
> having the same RefURI.
>
> Although I have to admit that this is a corner case, it is not so 
> unlikely as Signatures created with SignedReferences allow to create 
> multiple <ds:References> from the same input document and hence they 
> may having the same URI.
>
> Section 4.3 point 2. variant b. and also variant c. now ask to check 
> the matching <ds:Transforms> or the <ds:Transforms> and the 
> <ds:DigestMethod> to the <ds:References> inside the Signatures 
> <ds:SignedInfo>.
>
> However as the <ds:Transforms> and the <ds:DigestMethod> can be 
> arbitrarily complex like for example an XSLT <ds:Transform> bearing 
> the <xsl:sylesheet> directly, this can be very hard and expensive to 
> do. It might even out the usefulness of <dss:DocumentHash>, 
> <dss:TransformedData> for such cases.
>
> The comparison could amount to context free extract of the 
> <ds:Transforms> and <ds:DigestMethod> elements and the need to 
> canonicalize them if a true matching as required in section 4.3 point 
> 2 should be done.
>
>
> A straight forward solution to get rid of this problems would be to 
> introduce an attribute called <xs:attribute name="WhichReference" 
> type="xs:integer" use="optional"/> that identifies a reference and is 
> required in the case of a supplied <dss:TransformedData> or 
> <dss:DocumentHash> and would allow to ignore the given <ds:Transforms> 
> or the <ds:Transforms> and the <ds:DigestMethod> respectively.
>
>
> thoughts ?
>
>
> regards
> Konard
>
>