Re: unparsed entities

Hi Richard,

Actually signature filters are part of a larger system of 'filters' in XFDL
that can be used to describe what to write in, say, a network transmission,
so yes they do have application beyond digital signatures and hence it is
probably wise in the long run to view them as separate specifications (but
see below).

However, my current (limited) understanding of the canonicalization effort
is that it is trying to control how XML processors regenerate XML so that
one processor doesn't, for example, break a signature created by another
processor just because they write in different ways that are unimportant to
the XML derivative language.

In this view, canonicalization is mainly about "how" to write XML, whereas
filters as I've been describing them are mainly about "what" to write.  Once
you decide what to write, then canonicalization specifies how, but they are
two separate ideas.

Now because they are somewhat related, it is easy to see why they may not
have been separated.  In the same way, it's easy to see why I'd prefer not
to separate filters from digital signatures.  The problem is that there are
at least three different simple examples that I've given so far for why it
is necessary to have a mechanism that allows you to leave out pieces of the
document, and this is *just within XFDL*, so what are the possibilities
within all XML derivatives?

Basically, we can create a generic signed XML spec, but unless or until some
notion of filter is created, be that as part of canonicalization or part of
another spec effort, solving many of the digital signature problems that we
currently encounter is not going to be possible.  So we will therefore have
to soldier on using our own method, which means that more digital signatures
will be created that won't interoperate with other signatures when the specs
finally do come out.  Even though it is possible to adopt the position that
filtering is beyond the scope of signatures, the reality is that it will
have a big impact on the effectiveness of the signed XML standard if they
are left out.

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

-----Original Message-----
From: Richard D. Brown <rdbrown@globeset.com>
To: 'John Boyer' <jboyer@uwi.com>
Cc: w3c-xml-sig-ws@w3.org <w3c-xml-sig-ws@w3.org>
Date: Thursday, April 08, 1999 2:38 PM
Subject: RE: unparsed entities


>John,
>
>>
>> It seems that the signature filter idea could easily be
>> extended to say that
>> a signature should 'obtain' a list of resources, which could
>> then be put in
>> the signature element by the encoding routine before the hash
>> is generated.
>>
>
>What you have just depicted is, to some extent, what the XML Digital
>Signature Proposal recognizes as a Canonicalizer. I wrote "to some extent"
>because their initial purpose was not really to filter, but to produce a
>octet-stream representative of the semantics of the element being signed.
>But, Filter and Canonicalizer are very similar in their functionality -
>Being given an XML element (which could be the root) on input they produce
>the digest to be signed. Therefore, considering the flexibility of the
>Algorithm/Parameter definitions, it should quite straightforward to
>implement and parameterize an XFDL filter. In addition, the Canonicalizer
>definition (algorithm id and parameters) is already included in the
Manifest
>of the signature (thence protected).
>
>Conclusion: XFDL signs the form element making use of an XFDL canonicalizer
>which is provided on entry with element exclusion and inclusion patterns.
>Will this approach make sense to you and address your concerns?
>
>
>Richard D. Brown
>Software Architect - R&D
>GlobeSet, Inc. Austin TX - U.S.
>

Received on Friday, 9 April 1999 19:42:34 UTC