Re: Enveloped signatures

At 04:56 PM 6/8/00 -0400, Ken Goldman wrote:
 >I've been looking at the same problem (a collection of signed
 >documents within another signed document).  Below is my attempt at
 >an example.

Thanks for the well stated proposal [1] Ken. If I can summarize your points
and give my initial thoughts (others should pitch in too), let me know if I
misunderstood.

1. It is possible that signed IDs may collide (and cannot be changed) "when
combining two signed documents into a third." We've stated that the
requirement is part of the XML1.0 specification (and a necessary one). A
solution to this problem has not be addressed by a proposal that this WG has
consensus on. (And some feel (including me) it would not be approriate.)
Consequently, applications need to be careful.

2. Regardless of the above, the application might not be careful. You
present an example in which an application might interpret the validity of
some content based on the proximity of the syntax of the content to the
syntax of the Signature. This WG had two approaches to binding content to a
Signature: (1) binding via proximity (or the nesting of the XML) or (2) via
References. We've obviously went the Reference route and stated that
applications need be careful. I think your cogent example merits a sentence
or two in Security considerations at least.

3. You propose more than a few sentences <smile>. Presently, the
specification permits arbitrary URI specification with RECOMMENDED XPath
support and OPTIONAL XPtr support (other than the recognition of the Bare
Name syntax which is REQUIRED). Your proposal is to remove the requirement
for Bare Name support and REQUIRE a specific expression for identifying
document IDs; one that limits all ID based references. I have concerns on
this because of the following:

A. Specifying constraints of the URI="" attribute value is a new axis of
compliance (instead of a minimum support, it excludes potential expressions)
and one that is difficult to enforce. How would we formally specify this?
Can you define a schema pattern facet [2] that would do this?
B. Would such a pattern preclude other useful expressions?
C. Your screw case may be a desirable scenario to some applications that are
implemented properly; I think that's the case for the signing nesting
Signatures and their SignatureProperties.
D. It still doesn't solve the fact that collisions may occur, but
indemnifies the risk for sloppy applications.

[1] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0237.html
[2]
http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/datatypes.html#element-patt
ern

_________________________________________________________
Joseph Reagle Jr.   
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Wednesday, 14 June 2000 12:57:03 UTC