Re: KeyInfo questions/comments

Barb,

Yes I am saying KeyValue would be a burden for developers.  Implicit in the KeyValue requirement is an attempt to bridge trust management methods.  Such a bridge is not the charter of this group.  If trust management schemes are not interoperable, so be it.  Forcing KeyValue on a PKI-aware environment as inappropriate/difficult as forcing X509Data support on a non-PKI environment environment.  Furthermore, it is quite likely that the methods taken by different implementers to provide support for KeyValue in specific environments will introduce their own interoperability issues.  Why not require implementations that use KeyInfo to implement either KeyValue or X509Data/X509Certificate?  That seems like a reasonable solution.  

The DSA issue is related to parameter substitution.  The paper at the link I gave describes it in detail.  The premise of the paper is accepted in the X.509 world and there seems to be no reason to violate it here.    

-Carl 

  ----- Original Message ----- 
  From: Barb Fox 
  To: 'Carl Wallace' ; Barb Fox ; dsig 
  Sent: Monday, March 13, 2000 2:02 PM
  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 
    To: 'Carl Wallace' ; dsig 
    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) 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