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