RE: KeyInfo questions/comments

Peter--
 
Are you arguing that there is no value in sending information/hints about
what key was used to compute the signature?  To me, the contents of the
KeyInfo clause, if it exists, are valuble precisely because they provide the
entity attempting to verify the signature with hints to help him find the
correct public key.  KeyInfo clauses aren't intended as evidence carriers to
the verifier's trust management system; presumably if that was happening
in-band the information would be carried in other payloads with particular
semantics.  "Acceptance" of Keyinfo clause information for trust management
purposes isn't the intent and should not be an issue.
 
As a further question, when you and Carl speak of "PKI-aware" or
"PKI-enabled" applications, are you specifically talking about
X.509/PKIX-aware applications?  The two are quite different in my mind, the
latter being a small subset of the former.  In particular, I expect to see
entire public key infrastructures deployed based solely on signed XML
messages.
 
                    --bal

-----Original Message-----
From: Peter Hesse [mailto:pmhesse@cygnacom.com]
Sent: Monday, March 13, 2000 11:41 AM
To: Barb Fox; 'Carl Wallace'; dsig
Subject: RE: KeyInfo questions/comments


Barb,
 
Although KeyInfo is not too much a burden (heck, it's very simple) for
developers, there is a fine line between required-to-implement and
required-to-support.  IMHO, a PKI-aware (or for that matter, any
trust-management aware) application should not ever populate or accept
KeyInfo because it fails to provide any trust.  In that manner, why would it
need to be implemented if it would never be accepted?
 
Thanks,
 
--Peter Hesse
---------------------------------------------------------------- 
Peter M. Hesse   pmhesse@cygnacom.com   http://www.cygnacom.com
CygnaCom Solutions, Inc. (703)848-0883(voice) (703)848-0960(fax) 
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

-----Original Message-----
From: Barb Fox [mailto:bfox@Exchange.Microsoft.com]
Sent: Monday, March 13, 2000 2:03 PM
To: 'Carl Wallace'; Barb Fox; dsig
Subject: RE: KeyInfo questions/comments


Hi Carl:
 
KeyInfo is already optional. Are you saying that implementing KeyValue is a
burden for developers?  We chose KeyValue as mandatory to implement because
it's the only semantically-neutral option. Every other choice indirects the
public key, so this approach should guarantee the greatest range of
interoperability.
 
For DSA, think of the "key" as including these group parameters. To use a
key for validation of a signature, the recipient would need to have all
components of it (y, g, p, q) match the "key" he trusts.  
 
--Barb

-----Original Message-----
From: Carl Wallace [mailto:cwallace@erols.com]
Sent: Monday, March 13, 2000 10:24 AM
To: Barb Fox; dsig
Subject: Re: KeyInfo questions/comments


Barb, 

If the intent is to leave out issues related to trust management then I
suggest my proposal that no KeyInfo element be required is the best
solution. A digital signature specification that chooses to leave out trust
management issues is bound to have interoperability issues in that domain.
Attempting to find a common ground for interoperability without addressing
trust management is a tall order, and I contend that KeyValue only
complicates the issue for implementers. Consider an implementation that is
deployed in a PKI-enabled environment, a likely scenario. Why force it to
deal with KeyValue-related trust issues out-of-band, or otherwise, when such
issues can be dealt with cleanly using some combination of the X509Data
elements? There are plenty of places in the spec where application-specific
content can hinder interoperability, perhaps this should be another one. 

As for DSA parameters, there is no trust management architecture in which
DSA parameters used to validate a signature should be extracted from the
message they will be used to verify. As such, they need never be present in
the message and users can be spared passing around thousands of needless
bits by requiring their absence. 

- Carl

----- Original Message ----- 

From: Barb Fox <mailto:bfox@Exchange.Microsoft.com>  
To: 'Carl Wallace' <mailto:cwallace@erols.com>  ; dsig
<mailto:w3c-ietf-xmldsig@w3.org>  
Sent: Monday, March 13, 2000 12:24 PM
Subject: RE: KeyInfo questions/comments

Carl:
 
In response to your first issue:  Do not assume that because an application
includes a KeyValue as KeyInfo that the recipient does not have some a prior
validation for that key.  Unlike PKIX, we explicitly chose to leave trust
managment mechanisms out of this standard, and we selected KeyValue as the
MUST implement option to assure basic interoperability.  I believe that
presumption of a trust model (as in values passed must be trusted) is also
the basis of your second issue. 
 
Barbara Fox
Microsoft
 
-----Original Message-----
From: Carl Wallace [mailto:cwallace@erols.com]
Sent: Monday, March 13, 2000 8:18 AM
To: dsig
Subject: KeyInfo questions/comments


1) Why require support for unprotected, unvalidated keys?  It seems a little
strange to make KeyInfo OPTIONAL to accommodate applications that, for
whatever reason, do not wish to disclose KeyInfo then to mandate that
applications wishing to use some form of KeyInfo provide support for what
may be the weakest option.  Perhaps no KeyInfo option should be required.  

2) DSA support is required.  Where the KeyValue element is used to identify
a DSA key the presence of parameters is required (see section 6.4.1).  The
DSA parameter problem present in X.509 described by Santosh Chokhani (see
http://www.cygnacom.com/downloads/dsaflaw.zip
<http://www.cygnacom.com/downloads/dsaflaw.zip> ) is also a problem here.
Parameters found in KeyValue cannot be trusted, should not be used and thus
need not be included.  The requirement that parameters must be included
should be replaced with a requirement that parameters must be absent and be
obtained from a trusted source.

3) Section 4.4 states that "applications may define and use any (KeyInfo)
mechanism they choose through inclusion of elements from a different
namespace."  This doesn't appear to be possible given the current DTD and
schema definitions.
 
 
Carl Wallace
CygnaCom Solutions