W3C home > Mailing lists > Public > w3c-xml-sig-ws@w3.org > April 1999

RE: Perspective on signing XML 2

From: Richard D. Brown <rdbrown@GlobeSet.com>
Date: Fri, 23 Apr 1999 11:44:00 -0500
To: "'John Boyer'" <jboyer@uwi.com>
Cc: "'Dsig group'" <w3c-xml-sig-ws@w3.org>
Message-ID: <005a01be8da8$7e1a7d80$0bc0010a@artemis.globeset.com>

> 1) We're not trying to express the signature parameters in
> markup, so the
> DTD and world-wide implementations won't have to change when
> we add new
> signature technologies not currently envisioned.

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.

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.

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

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

> 4) By separating the cryptography from the act of signing, we
> can freely
> distribute the reference implementation and it becomes the deployer's
> responsibility to select and install signing technologies that are
> commensurate with the needs of the target organization.  The
> companies that
> produce the crypto layer have the export problems.  Whereas if the W3C
> reference implementation (complete with source code) has to
> have a crypto
> layer, it will be illegal for MIT to distribute it.

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.

> It's true that the signatures themselves will only be as
> interoperable as
> the underlying signing modules allow them to be.  Currently, we have
> interoperability between Netscape, Microsoft and Entrust
> digital signatures.
> This is because they all rely on the same (non-XML) standards.

I suppose that you make reference to their respective PKCS#7
implementations. If so, notice that they are not totally compatible and that
PKCS#7 addresses only a small subset of the current needs of the market.


Richard D. Brown
Received on Friday, 23 April 1999 12:43:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:44:59 UTC