Re: Comments on XML-Signature Core Syntax

RE: Comments on XML-Signature Core SyntaxAlthough, I agree in principal that the type of information carried as CMS attributes can be part of the XML signed Blob. One of the advantages of the CMS approach is the clear separation between the security related data  (the signed attributes) and the application data (the content). With the signed attribute approach,  all the data needed by the security process like a signature validation process is readily available at the time of signature validation, without having to decode the signed Blob.

I support Denis and think if the concept of signedAttributes and unSignedAttributes were added it would add value to the XML signature. The signedAttributes and unSignedAttributes should obviously be encoded using XML at the signedData level.

John Ross
  -----Original Message-----
  From: Barb Fox (Exchange) <bfox@Exchange.Microsoft.com>
  To: 'Denis Pinkas' <Denis.Pinkas@bull.net>; XML-DSIG <w3c-ietf-xmldsig@w3.org>
  Date: 25 October 1999 15:34
  Subject: RE: Comments on XML-Signature Core Syntax


  Denis: 

  The XML dsig working group had several months of discussion on this topic ("CMS features") and specifically rejected signed attributes among others. 

  In my own postings, I argued that there is no compelling need for attributes (authenticated or not) when you already have the expressive power of XML. If a signer wants to make qualified statements about a particular XML blob, then the signer should make those statements in XML (perhaps including a strong reference/hash of the original

  blob) and sign *that*.  In any event, you're always signing a particular XML 
  object. 

  I think you will also find that while we started with the notion of CMS-style signatures (wrapped only, requiring certificates, etc.) we evolved that model significantly to make it more appropriate to a broad range of web applications. These scenarios appear on the W3C page at http://www.w3.org/Signature/Drafts/xmldsig-scenarios-990818.html

  --Barb 



  -----Original Message----- 
  From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] 
  Sent: Monday, October 25, 1999 8:10 AM 
  To: XML-DSIG 
  Subject: Comments on XML-Signature Core Syntax 



  This is first version of the document has already a good shape. 
  However, I would like to raise several related comments: 

  It would be nice to be able to get the same features as those 
  present in CMS (Cryptographic Message Syntax). This seems nearly 
  there, but not completely. A major feature of CMS is the concept of 
  signed attributes which should be mirrored in this document. 

  In section 2.0, SignedInfo is defined as: 
     the actual data over which the signature is 
     calculated. It contains control information (algorithm 
     identifiers, pre-processing transformations) and digest(s) over 
     the object(s) being signed. 

  In section 1.3.4 it is said that: "additional objects have been 
  defined 
     which may be referenced by SignedInfo.  The Manifest element is 
     provided which similarly contains a collection of references and 
     objects (like SignedInfo), but leaves it entirely up to the 
     application which digest or digests it will verify." 

  This does not seem crystal clear. These additional objects are 
  equivalent to the signed attribuytes from CMS (what don't we use 
  that term as well ?) and thus must be verified by the application. 

  In section 4.0, it is mentioned that: 
     SignedInfo does not include explicit signature attributes. If an 
     application needs to associate attributes (such as signing time, 
     signing device, etc.) with the signature, it may add an 
  additional 
     Object that includes that data and reference that Object via an 
     ObjectReference. 

  It would be very nice to define such "useful attributes" in the 
  document itself. 

  A last, but related comment. In section 1.3.1 it is said: 

     KeyInfo indicates what key was used to create the signature. It 
  is 
     optional because in some applications the key is implied by the 
     circumstances. A wide variety of KeyInfo forms are available 
  including 
     certificates, key names, key agreement algorithms and 
  information, 
     etc. The keying information is outside of the signed information 
  so 
     that it need not be signed. KeyInfo might contain auxiliary 
     information it is not desired to reveal to all signature 
  verifiers. If 
     KeyInfo were signed, it would be necessary to pass all of it to 
  all 
     verifiers. On the other hand, if it is desired to bind the keying 
     information in to the signature, its digest and a pointer to it 
  can 
     easily be included in the signed information. 

  In order to prevent some substitution attacks of certificates 
  holding the same public key value, it is necessary to sign the 
  KeyInfo. Providing a standard way to do this (using the equivalent 
  of a signed attribute) would be most useful. 

  Denis