RE: Comments on XML-Signature Core Syntax

John:
 
I have to take issue with your statement: " 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)." 
 
In the XML space this isn't an advantage; in XML we do not need A PRIORI,
hard-coded semantics definitions to separate "application-related" data and
"security-related" data.  Furthermore, the underlying mechanics of CMS
assume that the entity generating the digital signature knows what
information is relevant to the signature verifier for making trust
decisions!  This may be true in the world of PKIX where everyone is required
to process and evaluate trust decisions in exactly the same way, but that's
not the world of XML and the web. Dragging XML signatures back into the
limited world scope of CMS is not something we're willing to do. 
 
--Barbara Fox
Microsoft
 
 -----Original Message-----
From: John Ross [mailto:ross@secstan.com]
Sent: Tuesday, October 26, 1999 2:21 AM
To: Barb Fox (Exchange); 'Denis Pinkas'; XML-DSIG
Subject: Re: Comments on XML-Signature Core Syntax


Although, 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
<mailto:bfox@Exchange.Microsoft.com> >
To: 'Denis Pinkas' < Denis.Pinkas@bull.net <mailto:Denis.Pinkas@bull.net> >;
XML-DSIG < w3c-ietf-xmldsig@w3.org <mailto: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
<http://www.w3.org/Signature/Drafts/xmldsig-scenarios-990818.html> 

--Barb 


-----Original Message----- 
From: Denis Pinkas [ mailto:Denis.Pinkas@bull.net
<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