Re: Valid XML and Schema Normative?

At 14:25 7/27/2000 -0400, Ken Goldman wrote:
 >We actually are considering using <SignatureProperties> as we try to
 >fit FSML into DSIG.  It's quite klunky because we designed FSML
 >assuming a smart card would be doing the signing.

BTW: I'd appreciate your thoughts on removing SignaturePropeteries as Gregor
noted it is superfluous to SignatureProperty [1].

[1] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0188.html

 >All of this has to be done atomically inside the card, or the security
 >is easily compromised.  It's not clear whether the extra processing
 >can be done in a cheap smart card.
 >
 >Is there a good reason not to permit tags other then references in
 >SignedInfo?  I can see that it's elegant the way it is, but why is
 >opening SignedInfo dangerous.
 >
 >In our application, if the smart card can't do the operation
 >atomically, we will have to trust the host application, which is
 >certainly dangerous.

Hi Ken, this is a good report on your experience. This aspect is one of the
earliest design principles:

2.2. XML-signatures are generated from a hash over the canonical form of a
signature manifest. (In this document we use the term manifest to mean a
collection of references to the objects being signed. The specifications may
use the terms manifest, package or other terms differently from this
document while still meeting this requirement.) 
http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014.html

This is a result of:

0. For all Signature applications, implementing the SignedInfo processing
logic is very easy, there won't be any surprises. Taking advantage of
SignatureProperties is more complex, but that's commensurate with its
relative position to validating a simple signature.
1. The early data model [1] which attempted to associate the syntax with an
assertion (digraph) based data model. Consequently, someone could run a RDF
parser over our syntax and pick up the relations of these things.
2. We want to provide the ability not to include it in SignedInfo (it's own
Digest or C14N Methods), consequently, supporting within and without is
unecessarily redundant. (Instead of supporting "inline" signature, and all
the others, the WG decided to choose the single method.)
3. It's proved useful in the rat-hole prone debate of Signature semantics.
If you have something to say about the signature, that is external to our
defintion of what a XML Signature is, place it outside of SignedInfo.

While I appreciate your implementation concerns this is a core design
principle that I don't think is likely to change at this point. (Though if
others have thoughts based on your experience they should weigh in.)


[1]
http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/xmldsig-datamodel-20000112
.gif

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

Received on Thursday, 27 July 2000 19:18:05 UTC