Re: Validity of signing n out of m items

From:  "Prince, Adam" <adam.prince@scala.se>
Resent-Date:  Wed, 24 Nov 1999 09:59:44 -0500 (EST)
Resent-Message-Id:  <199911241459.JAA17415@www19.w3.org>
Message-ID:  <01AE61A08304D211AD3900A0C995C2050363F2D5@serndexch.scala.se>
To:  w3c-ietf-xmldsig@w3.org
Date:  Wed, 24 Nov 1999 16:15:16 +0100

>Possibly I am misunderstanding the intent, but in section 2.4 of the XML-sig
>working draft it is suggested that some valid cases may exist where a single
>signature is created over multiple documents and an application may be
>defined so that it is possible (and acceptable) to validate the signature
>for n out of m items.  Leaving aside why an application might do this . .

It might really be a voting application.  Or, for a somewhat different
partial checking case, you might have something like IOTP where party
A calculates one signature over a bunch of messages, digesting each
separately, one intended for C1 if C1 is used in the transaction, one
for C2 if C2 is used, etc.  Then A sends this stuff to B who picks one
of the C's (Cn) and forwards a message with the signature and the
message from A intended for the Cn.  Cn can't possibly check the
hashes for the messages intended for the other C's because it does not
have them, nor does it care about them.  There may even be
confidentiality reasons not to reveal messages for other C's to
Cn. Party A did it with one signature because digests are
computationally cheap and public key signatures are expensive.

>I can only see two ways for a single signature to cover multiple items
>(blobs of data), either single DigestValue is created that uses a defined
>transformation to amalgamate the different blobs or multiple DigestValues
>are created.  In the first case, it is not possible to arrive at the same
>value if any of the underlying blobs are altered, hence n out of of m is
>mathematically not possible.  In the latter case a single signature is still
>based on amalgamating the DigestValues into a single item that is then
>signed (at least that is my understanding).  Again, if any of the digest
>values have changed (i.e. any of the underlying blobs have changed) then the
>signature cannot be verified and hence it is still not possible to validate
>n out of m!
> 
><Question>  Have I misunderstood the meaning of section 2.4, if so, can it
>be amended (either by elaboration or example) to clarify what is meant?
></Question>

It's probably because my eyes are used to it but I thought 2.4 was
pretty clear that it is not talking about SignedInfo but about a
Manifest of ObjectReferences that were referenced out of a single
ObjectReference in SignedInfo.  Whether this Manifest is examined in
any detail, let alone whether the DigestValues in it are checked, is
entirely up to the verifying application.

Applciations that don't recursively verify all the Digests in all the
Manifests referenced out of SignedInfo or out of other Manifests they
are checking may not meet your definition of verifying a signature but
the meet the definition stated in the current draft.

>Regards
>Adam

===================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668   dee3@torque.pothole.com
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     dee3@us.ibm.com
 Carmel, NY 10512 USA

>----------------------------------------------------------
>
>The options expressed in this communication are those of the sender.  They
>may or may not reflect the opinions of Scala Business Solutions N.V.
>
>Contact Details: 
>*(Office)       +46 8 601 1300 
>* (mobile)        +46 709 608 666 
>*(fax)            +46 8 718 4751 
>"(web)            <http://www.scala.se/> http://www.scala.se 
>* (e-mail)      <mailto:adam.prince@scala.se> adam.prince@scala.se 
>* (snail-mail)  PO Box 104, SE-131 07 Nacka, Sweden

Received on Wednesday, 24 November 1999 13:24:29 UTC