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

RE: KeyInfo and KeyValue

From: Brian LaMacchia <bal@microsoft.com>
Date: Tue, 14 Mar 2000 17:41:23 -0800
Message-ID: <39ADCF833E74D111A2D700805F1951EF0E32F1AB@RED-MSG-06>
To: "'Carl Wallace'" <cwallace@erols.com>
Cc: w3c-ietf-xmldsig@w3.org, "'Peter Hesse'" <pmhesse@cygnacom.com>
I've inlined my comments below, prefixed with [bal]...

-----Original Message-----
From: Carl Wallace [mailto:cwallace@erols.com]
Sent: Tuesday, March 14, 2000 4:40 PM
To: Brian LaMacchia; w3c-ietf-xmldsig@w3.org
Cc: 'Peter Hesse'
Subject: Re: KeyInfo and KeyValue

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."

[bal] Correct.  "Mathematical interop" is the process of cryptographically
validating the signature, and KeyValue helps with this.

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?

[bal] Your second statement is accurate; conforming applications may use
other means to retrieve the same keying material.  In fact, part of the
reason KeyInfo is OPTIONAL is that the precise key to use may be implied by
other means.  One can easily envision protocols built on top of XML-DSIG
that would take advantage of this option.

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.

[bal] Can you help me understand why these two sentences are not
contradictory?  Your second sentence implies that signature validation is
dependent on making a particular trust management decision about the key,
and further that the trust management decision requires building a chain of
certificates with some particular property.  Certificates, chain building,
and qualifying signature validation in this way are not fundamental to PKIs
in general, although they are properties of PKIX in particular.

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
minOccurs=0.

[bal] This last statement is false.  If you don't include the DSA parameters
then you have not fully qualified the key; without knowing the group
parameters how can you mathematically validate the signature using the
remaining info?  Remember that the parameters are not included anywhere in
the <SignatureValue> element.

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.

-Carl

[bal] Ah, I understand now, you are expecting from XML-DSIG statements on
items that are specifically beyond its charter (see the Constraints
subsection under Scope in http://www.w3.org/Signature/charter-20000105.html,
and Design Principles & Scope items 3.1 and 3.2 in
http://www.w3.org/1999/08/WD-xmldsig-requirements-990820.html).  Would
please identify what text in the draft led you to this expectation?  It
needs to be cleaned up.

					--bal
Received on Tuesday, 14 March 2000 20:59:41 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:09 GMT