W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 1999

RE: Comments on XML-Signature Core Syntax

From: Barb Fox (Exchange) <bfox@Exchange.Microsoft.com>
Date: Mon, 25 Oct 1999 07:32:18 -0700
Message-ID: <4992824A0863D211964B0008C7B1ACB803E1BA1C@fifi.platinum.corp.microsoft.com>
To: "'Denis Pinkas'" <Denis.Pinkas@bull.net>, XML-DSIG <w3c-ietf-xmldsig@w3.org>
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
Received on Monday, 25 October 1999 10:32:16 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:08 GMT