Re: unparsed entities

Hi Richard,


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

The external entities, once packaged into the document, can be signed
directly by simply regenerating a portion of the document that happens to
include the elements containing the packaged external entities.

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

Well, this is not really according to my logic.  There is nothing logically
wrong with the above example.  It's actually my sense of practice that would
usually recommend against such a system.  The reason is maintainability over
time.  Imagine having a million signatures all suddenly go invalid because
somebody canonicalized a stylesheet.  In an ideal world this would never
happen; in a semi-ideal world it would be easy to fix because everybody runs
regular backups, uses source code control, etc.  But in reality our support
group spends 75% of its time helping developer types figure out what they
broke, and often its not even in systems we sold them.  There just isn't the
kind of control out there that should exist.

Finally, I should also point out that I don't really oppose having a
standard that includes the ability for someone to create an application like
the one given in the example above.  All I'm really after is having a
signature standard that includes the types of things required by forms-based
applications which for reasons of transaction non-repudiation requires that
external unparsed entities be brought in and signed.  If this is acceptable,
then it is not a far reach to say that the spec should reflect as much of
this ability as possible so signatures on different document types can
interoperate.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
jboyer@uwi.com

>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 Wednesday, 7 April 1999 17:50:46 UTC