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

RE: KeyInfo and KeyValue

From: Barb Fox <bfox@Exchange.Microsoft.com>
Date: Wed, 15 Mar 2000 14:13:02 -0800
Message-ID: <997DBB511DD1D311A47A00508B6FB330ED0668@df-sparky.platinum.corp.microsoft.com>
To: "'Carl Wallace'" <cwallace@erols.com>, Brian LaMacchia <bal@microsoft.com>
Cc: w3c-ietf-xmldsig@w3.org, "'Peter Hesse'" <pmhesse@cygnacom.com>

I understand that you don't want to implement KeyValue. The fact that
KeyInfo is OPTIONAL and KeyValue is the one subclause of KeyInfo that is
mandatory-to-implement. This is consistent with other IETF RFCs. The idea
here is that if you DO include KeyInfo, then there must be a
mandatory-to-implement form. Do you have a suggested alternative for
KeyValue that is semantically neutral? 

I agree that we need some explanatory text on DSA parameters, but the
parameters cannot be omitted from KeyValue for cryptographic reasons
discussed previously. There is no scenario using KeyValue in which the
parameters can be left out. 

In terms of your issue with schema, I don't understand that. Maybe you would
also like to include an example of what you think needs to change.


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

My comments are inline and I've snipped away a great deal of text.

> [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
> other means.  One can easily envision protocols built on top of XML-DSIG
> that would take advantage of this option.

This is the core of my initial question.  KeyInfo is OPTIONAL.  Why require
those wishing to use a form of KeyInfo to implement KeyValue?  The fact that
it is optional undermines "base interoperability".  The fact that KeyValue
may be protected may further undermine base interop.

> 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
> 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
> certificates with some particular property.  Certificates, chain building,
> and qualifying signature validation in this way are not fundamental to
> in general, although they are properties of PKIX in particular.

I think we are arguing the semantics of the terms "validation" and
"verification".  Let's not.

> KeyValue does not change this fact.  And apparently KeyValue is not
> to do this.  In any event, the parameters are superfluous and should rate
> minOccurs=0.
> [bal] This last statement is false.  If you don't include the DSA
> 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.

This depends on your point of view.  If you accept that the parameters
should never be used directly from the message without outside confirmation,
due to parameter substitution, then it is logical to think that the
parameters could simply be obtained from the outside source and need not be
present in the message.  Having them there invites misuse.  Some verbage may
clarify this issue, but minOccurs=0 would permit implementations to avoid
including them where unnecessary just to claim "compliance".

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

Perhaps an explicit statement of the intent of KeyValue.  Perhaps some
elaboration/example of MgmtData and its relationship with KeyValue.  Perhaps
watch the use of the term validate which is used to describe both KeyValue
and X509Data since it has different meaning in each location.  Perhaps use
verify instead when discussing KeyValue.

Lost is this has been the question whether or not the DTD/Schema is
sufficient to support stated usage of KeyInfo.

Received on Wednesday, 15 March 2000 17:29:23 UTC

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