KeyInfo and KeyValue

There seems to be a bunch of confusion about the role of KeyInfo clauses and
suppositions about particular environments in which XML-DSIG is expected to
operate.  I'm combining responses to Peter and Carl here in the hope of
pulling things back together.  Apologies in advance for the length.

First, Peter wrote:

	Brian, 
	Sorry for the confusion. I misspoke in my email. I meant KeyValue,
not KeyInfo. KeyInfo is very valuable. KeyValue is a specific form of
KeyInfo. Mandating that the KeyValue type of KeyInfo is required to
implement is not good. That's because KeyValue is the "actual key(s) used to
validate the signature. If the key is sent in protected form, the MgmtData
element should be used." 
	So what I'm saying is that sending an unprotected key by using the
KeyValue mechanism does little good in a trust-management environment, such
as an X.509 or PKIX environment. I'm concerned that (A) by populating
KeyValue, I might encourage users to simply verify the signature based on
the contents of KeyValue without even attempting to validate my certificate
or certificate path, and (B) by making my implementation accept KeyValue, I
open myself up to accepting signatures that I shouldn't trust. 
	Since neither A or B is acceptable in a PKI environment, I would
rather just not bother with KeyValue at all. Thus we'd like to see it not be
a MUST implement. 
	--Peter 
I think the problem here may stem from the wording Peter highlights and a
confusion of two separate operations: (1) cryptographic signature
validation, and (2) trust management determinations about a particular key
pair.  These are two fundamentally separate concepts within XML-DSIG; we
explicitly separate the process of "verifying" that a digital signature is
well-formed (computationally correct) from determining whether to place any
trust in the key pair that performed the digital signature operation or the
semantic content of the properly-signed message.  Our primary concern is
with step (1), so we care that conformant implementations always have a way
to communicate enough information to perform the cryptographic signature
check.  That's why KeyValue support is required; it guarantees that two
XML-DSIG implementations have at least one method of communicating enough
information to cryptographically validate the signature.  
Now, the wording quoted above from Section 4.4, that KeyValue contains the
"actual key(s) used to validate the signature," seems to imply that the
information in KeyValue *must* be used by the verifying application.  This
was never the intent of anything contained within KeyInfo, so the language
in the draft clearly needs to be revised. There is no requirement that the
verifying implementation use the specific information contained within
KeyInfo in the actual signature validation, although (as in CMS) we expect
that for efficiency reasons implementations will likely try the included key
information first before hitting a database to look for other potential keys
to use to validate the signature.
Once the signature has checked out, trust management models come into play
(step (2)).  Here XML-DSIG makes no statement about how individual
applications may choose to perform step (2), or even what information that
may use to make such determinations.  We provide a place, KeyInfo, in which
applications may choose to communicate information that may be useful for
step (2), but again there's no requirement that that mechanism be used.
I agree with you that "sending an unprotected key by using the KeyValue
mechanism does little good in a trust-management environment;" but that's
not an issue here because we're not trying to convey trust to the trust
management engine via the KeyValue clause.  As for your two other concerns:
	I'm concerned that (A) by populating KeyValue, I might encourage
users to simply verify the signature based on the contents of KeyValue
without even attempting to validate my certificate or certificate path, and 
This statement doesn't make sense because it combines steps (1) and (2),
which are explicitly separate.  For performance reasons it's quite likely
that verifiers will try the provided key information first to satisfy step
(1).  That doesn't help with step (2), though, and clearly implementers of
XML-DSIG must understand the difference between these two steps and what
information they get out of each of them.  As an aside, I assume that your
use of "certificate or certificate path" is simply a stand-in for whatever
evidence your trust management engine chooses to accept.
	(B) by making my implementation accept KeyValue, I open myself up to
accepting signatures that I shouldn't trust. 
Again, this statement confuses signature validation from trust management
processing.  Perhaps we need more explicit language in the draft calling out
the fundamental difference between the two.
Moving on, Carl wrote:
	Thanks to Brian's comments I understand now the idea is for KeyInfo
to serve as a "hint" and little/nothing more. However, I still fail to see
where KeyValue provides anything in the way of "base interoperability" where
a PKI application receives a key via KeyValue from a non-PKI application and
thus fail to see why KeyValue is required. It seems only to provide enough
interoperability for a non-PKI application to deliver a key that cannot be
validated to a PKI application. 
I don't understand the distinction Carl's trying to draw here between "PKI"
and "non-PKI" applications.  I believe there may be some confusion because
in PKIX applications keys are always delivered as part of the PKIX evidence
(i.e. PKIX certificates) used as input to PKIX trust management processors
(i.e. PKIX chain builders & path validation logic).  There is no assumption
in XML-DSIG that any particular trust management engine will use particular
forms of evidence that embed keys.  PKIs, in the abstract sense, deal
primarily with making the trust management decisions that form step (2)
above.  Since we cannot assume the existence of any particular form of PKI
in XML-DSIG, let alone one that always conveys keys inside trust management
evidence, XML-DSIG must provide the base interop for doing cryptographic
signature checks.
I hope this helps clear things up,
					--bal

Received on Tuesday, 14 March 2000 18:34:36 UTC