Re: Unparsed Entities (signature filters)

Hi Richard,

Thanks for asking; info below.

>However, you raise one point that is quite interesting: should we provide
>the ability to identify authenticated resources in the Manifest either by
>means of a reference (XML Link and Hash) or by value (package sub-element)?
>This is a bit different from what I have proposed: packaging can be done
but
>outside the Manifest.
>
>Nonetheless, this does not really change my opinion regarding the fact that
>the Signature Standard shall not require the signature engine to "chase"
>given external entities. Somewhere I feel that our divergence may be due to
>different concept regarding the API that is used at the end.
>
>Are you contemplating something so that in final you sign an XML document
>that is input as a stream in the signature engine?
>
>  SignatureEngine engine =new SignatureEngine();
>  engine.setParameter(...);
>  engine.encode(inputStream, outputStream); // envelope approach (i.e.
>S/MIME)
>
>Or do you envision something where you explicitly indicate the elements (or
>resources) that should be authenticated?
>
>  Signature sig =new Signature();
>  sig.setParameter(...);
>  sig.addResource(element1);
>  sig.addResource(element2);
>  Element xsig =sig.encode();
>
>In the first case, the standard must specify global attributes to identify
>which elements must be authenticated. In the second case, this is the
matter
>of the application layer to identify these elements. Which approach has
been
>adopted for XFDL?
>

In XFDL, we don't separate the data,  presentation, and presentation logic
layers.  With regard to signatures, this is similar to saying that a
stylesheet is 'somehow' brought into the XML document before we sign some
portion of the XML.

So, although we don't have the "chase down the resource" problem, it is
technically similar to other problems that we solved with a signature
filter.

The signature filter expresses--in the markup-- the subset of the document
that should be encoded.  Any element that matches certain patterns is either
kept or omitted.  So, our method is more like the second block of code.

>  Signature sig =new Signature();
>  sig.setParameter(...);
>  sig.addResource(element1);
>  sig.addResource(element2);
>  Element xsig =sig.encode();

When someone presses a signature button on an XFDL form, we would create a
signature object, and we would set up parameters, which incidentally may be
expressed in the form (such as what cryptographic service provider to use).
The sig.addResource() calls are essentially another way of expressing this
idea of signature filter, except that there are no imperative.  Instead, the
sig.encode(theForm) procedure knows how to read the signature filter in
theForm and do pattern matches to decide whether or not to include each
element in the message to be hashed.  The subset of the document selected is
still in valid XFDL (and hence valid XML), and this is what gets hashed.
The encrypted hash along with the signers certificate (PKCS7 blob) are then
base64'd and stuck into the signature element being created in the form.
Actually, the signature element is created before the hash, and copies of
the signature parameters and signature filter from the signature button are
added before the hash.  So, the only thing that gets added after hashing is
a subelement that  contains the base64'd pkcs7 blob, which the verification
obviously omits when recomputing the hash.

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.

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


>Sincerely,
>
>Richard D. Brown
>Software Architect - R&D
>GlobeSet, Inc. Austin TX - U.S.
>
>