W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

Re: SHOULD / MUST see what was signed

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Tue, 08 Aug 2000 17:11:59 -0700
Message-Id: <3.0.5.32.20000808171159.0197f3d0@localhost>
To: Don Davis <ddavis@shym.com>
Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
At 14:12 8/4/2000 -0400, Don Davis wrote:
 >WG's work.  from conversations with the WG's co-chair joseph reagle,
 >i understand that my concerns revisit issues that were discussed
 >thoroughly in the group, long ago.  i've seen some of those dis-
 >cussions in the WG list's archive.  so, i'm prepared to accept
 >regretfully that by now, my comments may be familiar and out-of-
 >scope for the WG.  if so, perhaps my remarks can be recorded as
 >"public comments." 

Hi Don, I think the WG's direction at this point in time is pretty much set,
however it is possible that the specification isn't doing a good a job as it
could be of communicating that direction to others -- who haven't been
arguing about this and related issues for the past year!

 >i believe that for xml signatures to be fully useful in commercial
 >security applications, the draft should make it easy for implemen-
 >tors to understand how to calculate legally enforceable signatures
 >on behalf of human signers.

As odd as it may sound, we consider this an applications issue for a couple
of reasons. It's hard (i.e. not likely to get done in a reasonable amount of
time), we are serving a range of applications (low level protocols to forms
processing), there's little agreement on how to do it, and the meaning of a
document format is determined by its own specification and use.
Consequently, we set out to define a simple signature syntax that provides
for 'signature validity': associating a key with octets so as to provide
data integrity, authenticity, and key non-repudiation (in asymmetric key
systems). [1] Within the Signature specification we aren't normatively
specifying how a key relates to a person or institution, nor what those
octets mean. (The only octets we concern ourselves with are those that make
up the Signature element type itself.)

[1]
http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014.html#design-princi
ples-scope

 >we would like, because the current spec would oblige us to write
 >these high-level secure-xml libraries ourselves, though we are a
 >crypto shop, not an XML shop.  

This is correct. Applications will have to make a number of decisions about
the cryptographic algorithms _used_ (e.g., selection and key strengths,
etc.), transforms (e.g., XPath, XSLT, etc.), and even meaning of the
Signature in their context. On the meaning note, consider that the checkbook
application had to define (and enforce) what it means by 'authorized by':

<checkbook>
  <check Id="check101">
    <account>xyz</account>
    <amount currency="USD">50</amount>
    <authorized by="#Signature101"/>
  </check>
  <Signature Id="Signature101" xmlns="http://www.w3...">
    ...
    <Reference URI="#check101"/>
    ...
  </Signature>
</checkbook>

 >so,  for automated signatures, i agree with mr. eastlake that
 >SHOULD is appropriate.

I don't think the question is the degree to which we think this is
important, but to be clear about our definitions and conformance
requirements. We are focusing our use of those key terms on those things
that affect interoperability with respect to the generation of the
SignatureValue.

Regardless, if the WG is not willing to pursue the path of using MUST with
respect to security recommendations regarding signatures that humans
interact with, I think it would be a good idea to perhaps include a sentence
right up front (maybe in the introduction) stating our intent: that this
specification provides an component that is necessary but not sufficient nor
complete component of using XML to communicate legally binding semantics
between users, with a reference to section 8: Security Considerations.

 >though, i strongly suggest that a signed document's human-inter-
 >pretable representation must have three essential properties:
 >        * "see what's signed:"   human signers and verifiers MUST
 >           get the same human-interpretable representations.
 >        *  portability:  the signer or verifier must be able to
 >           show a court the same representation he read or heard,
 >           without having to carry his file-server's xml config-
 >           uration to court. 
 >        *  stability:  for long life, a signed document's represen-
 >           tation must not depend on changeable external stylesheets,
 >           transforms, or parameters, unless those external components
 >           are signed, too.
 >all three properties refer to a notion of "sameness." 

I think these properties are important and belong in signature legislation
and/or application policies when they define the context of their
application.

 >because the draft fails to require "MUST see what was signed,"
 >i suggest that the draft violates one of the XML Signature
 >Requirements [7] that is central for XML signatures' security:
 >
 >   "4. The signature design and specification text must
 >       not permit implementers to erroneously build weak 
 >       implementations susceptible to common security 
 >       weaknesses (such as downgrade  or algorithm
 >       substitution attacks)."
 >                - sec  3.3, "Cryptography and Processing," [7]
 >
 >this is exactly my complaint about the current draft spec.  compliant
 >implementations can verify a signature as valid, even when unsigned
 >transformas and external references have caused the document represen-
 >tation's contents to change substantially.

This is a good point though the text was intended to deal with cryptographic
processing.  With respect to XML issues, we acknowledge that it's tricky
ground (XML itself is green as evidenced by all the canonicalization
discussion), but it's a problem folks felt like tackling given the balance
we struck in requirement 2.3 . Given that our mutual goal is to be clear
about the intent and use of the specification, if we can't reach that
through saying MUST in section 8, perhaps a sentence or two up front can?

Consequently, what do people think of a paragraph along the lines as the one
added [2] below:

[2] http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/#sec-Introduction

1.0 Introduction
...

/+This specification defines a method of associating a key with referenced
data (octets); it does not normatively specify how keys are associated with
persons or institutions, nor the meaning of the data being referenced and
signed. Consequently, while this specification is an important component of
secure XML applications, it itself is not sufficient to address all
application security/trust concerns, particularly with respect to using
signed XML (or other data formats!) as a basis of human-to-human
communication and agreement. Such an application must specify additional
key, algorithm, processing and rendering requirements. For further
information, please see Section 8: Security Considerations. +/





_________________________________________________________
Joseph Reagle Jr.   
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Tuesday, 8 August 2000 17:11:22 GMT

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