RE: SHOULD / MUST see what was signed

Hi Don,

I am certain that I am among the advocates who feel that an XML signature
can only be legally binding if all components necessary to recreate what the
user actually 'saw' are reproduced (for visually impaired persons, we assume
either that a different XML document appropriate to their needs was created
(e.g. one involving sound operatives) or that the appropriate application
tool was applied to the markup (e.g. IVR rendition)).

However, I do think that the spec adequately addresses our mutual concern
without the need for an enormous amount of extra programming on your part.

In my opinion, the two external information entities which qualifies what
one sees that will be most used are images and stylesheets.  An image can be
that of a corporate logo, which can have a profound effect on whether one
chooses to sign.  And an XSL stylesheet is most often used to match XML data
and describe how to present it by producing as output HTML with the
important parts of the XML data embedded.

In both cases, a signature on the XML is at least suspect and more likely
useless without having the signature also cover the externally referenced
information.  The Signature element provides the capacity to set this up
such that the XML libraries you procure should function as you want without
any extra programming on your part.  In fact, there are cases where it can
be done in multiple ways.

If you would like to sign your XML data plus some external image or other
binary file, you simply add an extra Reference to your Signature element.
If you would like to qualify your XML data with an XSL transformation, you
can either sign the XML data plus add an extra reference to sign the XSL
stylesheet, or you can add the stylesheet as a Transform, so that you can
sign the output result.

The principal difficulty is in writing software that could, for all XML
markup, determine the external information entities required to completely
specify the signing context.  For example, how do you know that images are
being referenced, esp. if they are only referenced by the result of an XSL
transform?

It is simply not possible to assess the external dependencies of any XML
document.  XML is a grammar with no lexicon.  Those who intend to use XML
must invent a lexicon and a set of semantics for that lexicon.  Any keyword
can be created by the lexicon's creator, and its associated meaning can be a
reference to an external document.  For example, XHTML still contains an IMG
tag with a SRC attribute, even though XML has a facility-- often not used--
for referring to external unparsed entities.  Moreover, a keyword could
refer to multiple references with the semantic that the digest validation of
any one of them is sufficient (some copies of a resource may be
non-accessible or non-applicable in certain regions).

Since all of these semantics have not yet been defined, there is no way that
we can define an algorithm that resolves the semantics to determine the
correct set of external references that MUST validate in order to produce
the legally binding signature.  Instead, what we are providing is the
facility for specific applications (i.e. lexicon deployments) and more to
the point specific documents to have Signature elements that are crafted to
fit the particular needs of that document.

In conclusion, we did not feel the problem was solvable by middle-ware XML
signature implementations such as the one you want to build.  Only the
end-user application can examine the document in the context of its
application-specific XML lexicon/semantics to determine the external
entities that must be part of the signature, and then read the list of
References to ensure that the material was included.

Although this is one way to solve the problem, I actually believe that a
completely different route will be taken.  I think that the presentation
layer, the rules for moving data from XML data structures into presentation,
and the Signature element that captures these business rules will be vetted
either by the validator or by independent parties.  I think that the party
that approves the document will do so by signing the bits that have been
approved, a sort of seal of approval.  Finally, I think that a signature on
an actual legal agreement will cover the data added to specify the terms of
the agreement as well the approval signature.  This scheme would work
particularly well if the approval phase were done by an independent
organization.

For example, suppose we are dealing with a financial document such as a
mortgage application.  The validator is the bank, the approver of the
electronic mortgage application would be either the bank itself or by an
independent organization-- a Bureau of Electronic Banking Documents.  The
validator can be the bank when the signer trusts the bank, and the bank
simply wants to ensure that neither the signer nor a 3rd party interfered
with the operation of the document in unapproved ways.  The signer is also
likely to retain an e-copy of the document, so if there is a dispute, the
signer can have the document examined by an expert.

Anyway, the point is that I doubt that even the end-user application will
have to directly determine the external information dependencies and test
whether they were signed.  The validation of certain signatures is likely to
be the extent of application code.

Thanks,
John Boyer

     John Boyer
      Development Team Leader,
      Distributed Processing and XML
      PureEdge Solutions Inc.
      Creating Binding E-Commerce
      v: 250-479-8334, ext. 143  f: 250-479-3772
      1-888-517-2675   http://www.PureEdge.com


  -----Original Message-----
  From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Don Davis
  Sent: Friday, August 04, 2000 11:13 AM
  To: IETF/W3C XML-DSig WG
  Cc: Don Davis
  Subject: SHOULD / MUST see what was signed


  i'm a cryptographer and security architect for shym technologies,
  a PKI "middleware" startup here in needham, MA.[1]  i've done a
  lot of work on security and crypto, including PKI, starting with
  my work with ralph swick on kerberos protocol extensions [2], when
  i worked at mit's project athena during the late '80's.  since
  then, i've mostly worked as a management and technical consultant
  for very large financial, corporate, and institutional organizations,
  but i've also worked for various small security-related high-tech
  companies.  i've also published a number of papers on cryptography
  problems. [2]

  i've recently read the WG's july 11 draft [3], and some supporting
  w3c documents, so as to help my employer decide whether or when we
  should support XML signatures in our products.  i'm now writing to
  offer my comments to the WG, though i haven't been following the
  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."

  summary of my remarks:
  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 the draft stands, i do not expect
  xml vendors will soon supply the kind of high-level secure-document
  libraries that my company wants to undergird with our PKI crypto
  products. thus, my company faces a higher implementation cost than
  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.  i'm also very disappointed that sec
  8.1 of the july 11 draft [3] doesn't require "see what was signed"
  for human-chosen signatures.  i claim that this omission violates
  sec. 3.3, bullet 4 of the XML Signatures Req'ts doc't [7].  if the
  subject of "MUST see what was signed" is closed to further discus-
  sion, then i earnestly ask that the w3c address such a feature in
  a separate WG, to build on this WG's progress.

  my full comments follow, for 3 more pages.  my text follows a
  recent discussion of this topic on the list, under the subject
  header, "XML Processing in Current Implementations:"

  joseph reagle wrote:
  > If a PI references a style sheet, this could change the meaning
  > of the document being signed, is this change also signed? [4]
  ...
  > 2. ... we'd have to recommend that 'http://foo.example.com/bar.xslt'
  > also be included in a Signature Reference if we want to get bit by
  > having foo.example.com changing the stylesheet to affect the result
  > after the signature. [4]
  ...
  >  " /+... if an XML document includes an embedded stylesheet [XSLT]
  >  it is the transformed document that SHOULD be represented to the
  >  user and signed. To meet this recommendation where a document
  >  references an external style sheet, the content of that external
  >  resource SHOULD also be signed via a signature Reference --
  >  otherwise the content of that external [resource] might change
  >  which alters the resulting  document without invalidating the
  >  signature.+/" [5]

  donald eastlake replied:
  > I am leary of MUSTs in this area. ... If an external style sheet
  > is referenced there is no reason to include or sign it if it is
  > determinable by the protocol and all receivers have a copy which
  > is authentic by definition. Etc. [6]

  i agree that when software applies a signature automatically,
  there's no reason to worry about signing external references.
  but, when a human must choose deliberately to apply a signature,
  there's ample reason to sign external references.  these two
  scenarios differ in two important ways:
          *  a human's deliberate signature tends to be long-lived,
             while an automated signature tends to be short-lived;
          *  with a human's deliberate signature, the human-interpretable
             representation tends to be legally binding,  while with
             an automated signature, the underlying document format
             tends to be more important than the human-interpretable
             representation.

  so,  for automated signatures, i agree with mr. eastlake that
  SHOULD is appropriate.  for deliberate human-chosen signatures,
  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."  no doubt,
  the application designer must decide what's "the same," and what's
  not.  in some contexts, pixel-by-pixel match-up may be necessary;
  in others, font changes may be acceptable, without violating this
  notion of "sameness;"  in other contexts still, even automated
  translation from text to audio might be an acceptable change that
  shouldn't invalidate the signature.

  i've seen discussed three alternative ways to guarantee these
  signature-properties:
          *  "...it is the transformed document that MUST be
             represented to the user and signed."  (paraphrasing
             mr. reagle's 8/1 message [5]).
          *  or, the signature can apply to all external references
             that affect the human-interpretable representation.
          *  or, the signed document can carry a separate signature
             for each external reference that affects the human-
             interpretable representation.
  all three seem acceptable to me.  thus, i suggest that when a
  human signs an XML document, the signature must be bound either
  to a human-interpretable representation of the document, or else
  to a fixed procedure for preparing such a representation.

  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.  it's arguable whether my
  concern is more of a security problem than a crypto problem, but plainly,
  the bullet 4 text speaks both to crypto flaws and to security holes.

  from my reading of the current draft, compliant and useful
  applications can be written for either type of signature,
  human-chosen or automatic.  but, the draft offers several
  pitfalls for an application programmer who wants to support
  legally-binding human-chosen xml-signatures.  mr. reagle's
  external stylesheet example, cited above [4], is an example
  of such a pitfall.  other examples are external references
  to pricing data, or to boilerplate contractual terms.  as
  a cryptographer and security architect for a PKI security
  company, i'm very concerned that XML signatures should
  _gracefully_ support both automated signatures and humans'
  deliberate signatures.  i know that this is a lot to ask of
  one specification.  but with the current draft language, i
  regret that i cannot recommend to my company or to our cus-
  tomers that XML Signatures are suitable as yet for human-to-
  human signature applications.
                                                          - don davis,
boston

  [1] my employer:         http://www.shym.com
  [2] my work with swick:  http://world.std.com/~dtd
  [3] the draft i read:

http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/#sec-Security-Transofrms
  [4] reagle's mail:

http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0192.html
  [5] reagle's text:

http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0213.html
  [6] eastlake's reply:

http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0214.html
  [7] requirements:

http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014.html#Cryptography



  -