Re: Perspective on signing XML 2

Hi Richard,

>This implies that the current definition (markup) is probably insufficient,
>while assuming at the same time that we can be exhaustive with a crypto
>engine approach - may be but I'm not yet convinced.

I hope to convince you by pointing out that below you indicate that the
philosophical paradigm I'm talking about is equivalent to the definition of
signature algorithm.  Therefore, it is exhaustive by definition since
anything that claims to be a signing engine can be accommodated.

This is not to say that anything in the current IETF draft is being excluded
by what I'm talking about since it would be another signing engine.

>
>On the other hand, I am pretty sure that one can leverage the existing
>proposal (markup) for supporting PenOP - PenOP is only a different
>authentication algorithm (though an engine in real) with a different set of
>credentials and potentially some additional parameters. All these pieces of
>information can be encoded with the current markup.

Yes, Donald also mentioned this.  Could you show me how I might do this?
That might help a lot.

>
>In fact, the difference between your approach and the current proposal is
>very much philosophical. You depict a crypto-engine as a black-box that
>exposes the following two methods:
>
>    signature_blob Sign(something, with keying-material, with <other
parms>)
>    bool Verify(something, signature_blob, with keying-material, with
<other
>parms>)
>
>This is pretty much the definition of a signature algorithm.
>
>The main difference consists of the identification of the parameters being
>passed to the crypto-engine (method). In the proposal they are sealed in
the
>Manifest, so the XML-DSIG engine does not have to further establish what
>need to be fed in the crypto-engines. All the pieces of information have
>been declared in the Manifest. In your approach, I don't know yet if you
>expect to standardize the calls to the crypto-engines, adopt crypto-engine
>profiles, or define a syntax to encode the parameters. The only one that
>would make sense in regard to your arguments is probably the second
>approach, though a new profile will have to be defined for every new
>crypto-engine.

Yes, exactly crypto engine profiles.  And yes every new crypto engine would
need one.  This would allow crypto engine manufacturers to specify how their
technology fits into the framework of signing XML.  This would include the
crypto engine specified by the IETF draft.

>Not quite correct. For example, I can put together a reference
>implementation in Java that relies upon the Java Cryptographic Extension
and
>not have to ship any crypto modules. There are several JCE providers
>world-wide that can be plugged under JCE. The "trick" consists of making
use
>of a standard crypto-api.
>

Good point.  However, part of my concern is that translating between XML and
the blob format of any particular crypto engine means that I have to know a
lot about the blob format of every crypto engine I in order to communicate
with it.  This is impossible to do with something like PenOp, but also
taxing in general.  It feels unnatural from an encapsulation point of view.
In general, APIs hand you data blocks that you are expected to pass around
to other functions in the API.  One shouldn't be constructing or
deconstructing the data blocks for these APIs.  For example, with the
Microsoft API, I call CryptSignMessage() and
CryptVerifyDetachedMessageSignature(), passing the latter the datablock
provided by the former.  There are functions I can call on that data block,
but in general these toolkit APIs will have to be expanded to really provide
the flexibility of the IETF draft in function calls.  So, again we get back
to the idea that currently deployed PKI would have to be replaced, which is
an unjustifiable cost if there exist ways of signing XML that don't require
it.

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

Received on Friday, 23 April 1999 19:53:32 UTC