RE: unparsed entities

John,

What is being signed shall be explicitly specified in the signature manifest
by means of XML links. Thus, if an external/unparsed entities needs to be
embedded into the signature process then this entity shall be packaged into
the document and a link to the package element shall be inserted in the
signature manifest. Conversely, if you can suffice with an external
reference to the resource, but still want to bind the actual value of this
resource into the signature process then you should insert both the hash and
the reference to this external entity into the signature manifest. Notice
that you should not expect the "signature engine" to verify that the hash of
the external entity matches with the one inserted in the signature manifest.
An implementation that complies with the standard should only assess that
the signature value is valid in regard to the signature manifest. It falls
under the responsibility of the application layer to verify the actual value
of the external entity.

Let consider some rating report that consists of several thousand of
assertions regarding external entities. According to your logic, the
signature on the report cannot be deemed valid unless all links are
verified. This means also that either all or none of the assertions are
valid. In fact, the semantics of such assertions could have been something
like "I <signer> certifies that the resource located at <link> in a state
<hash> is ...". So, any assertion is verifiable independently of the others.
But, this stands true only in this particular context. The point is that
only the application layer knows about what should be verified beyond the
content of the signature manifest. You can certainly define more flags and
attributes in the manifest so that you can tell the signature process what
to do in all circumstances. Unfortunatelly, there will be always somebody to
find something new and this will require one more attribute. Also, if the
standard mandates that compliant signature implementations shall follow
given links as part of the signature computation or verification process
then you require that every single signature implementation be provided with
transport capabilities. This is far from being common pratice, and in most
circumstances, processes involved in signature verification or computation
are shielded from the external networks (for obvious security reasons).

Sincerely,

Richard D. Brown




> -----Original Message-----
> From: w3c-xml-sig-ws-request@w3.org
> [mailto:w3c-xml-sig-ws-request@w3.org]On Behalf Of John Boyer
> Sent: Tuesday, April 06, 1999 3:35 PM
> To: Dsig group
> Subject: Re: unparsed entities
>
>
> Richard,
>
> OK, so how are you proposing that various applications
> interoperate if they
> can't read one another's specifications for regenerating what
> got hashed?
> Interoperability is implied by XML goals 1, 2 and 4, so it
> seems we should
> push interoperability in a signed XML standard.  If that is
> reasonable, then
> it follows that we need, as part of the spec, to have a way
> of defining what
> gets signed and what doesn't get signed so that all
> signed-XML-compliant
> applications will do the same things.  This would seem to
> imply the need
> both for digital signature filters and for differentiating
> links that should
> be chased versus links that shouldn't.
>
> John Boyer
> Software Development Manager
> UWI.Com -- The Internet Forms Company
> jboyer@uwi.com
>
>

Received on Tuesday, 6 April 1999 23:31:39 UTC