- From: Don Davis <ddavis@shym.com>
- Date: Fri, 04 Aug 2000 14:12:32 -0400
- To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
- Cc: Don Davis <ddavis@shym.com>
- Message-Id: <4.1.20000804140151.009fb180@smtp>
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
-
Received on Friday, 4 August 2000 14:12:32 UTC