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

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

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

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.

-Carl

Received on Tuesday, 14 March 2000 21:29:48 UTC