W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2000

Re: KeyInfo and KeyValue

From: Carl Wallace <cwallace@erols.com>
Date: Tue, 14 Mar 2000 19:39:46 -0500
Message-ID: <003f01bf8e16$f70221c0$477c60cf@ornette>
To: "Brian LaMacchia" <bal@microsoft.com>, <w3c-ietf-xmldsig@w3.org>
Cc: "'Peter Hesse'" <pmhesse@cygnacom.com>
Armed with an understanding of the intent, which is, as you point out, not
apparent in the text, I think what you are saying is this: KeyValue provides
mathematical interoperability.  This appears to be the gist of your comment:

    "XML-DSIG must provide the base interop for doing cryptographic
signature checks."

If this is so how is your following statement true:

    "there is no requirement that the verifying implementation use the
specific information contained within         KeyInfo in the actual
signature validation."

What interoperability is achieved if I can populate KeyValue with anything
other than the "actual key(s) used to validate the signature?"  Or do you
simply mean that I may use other means to retrieve the same keying material
for actual use?

Note that my distinction between PKI and non-PKI has nothing to do with
PKIX.  I was simply stating that when given a raw key from a non-PKI
environment that a PKI app will fail to validate a signature generated using
that key because a satisfactory certification path cannot be built.
KeyValue does not change this fact.  And apparently KeyValue is not intended
to do this.  In any event, the parameters are superfluous and should rate a

While the mathematical interoperability facilitated by KeyValue is important
I think the text describing it creates the illusion of a interoperability at
a higher level where there really isn't interoperability.  By not addressing
specific trust management schemes, we cannot deny their existence nor the
fact that interoperability issues exist between them.  Perhaps text changes
shall clarify the issue.  I await the next draft.

Received on Tuesday, 14 March 2000 19:41:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:33 UTC