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

Re: Valid XML and Schema Normative?

From: Ken Goldman <kgold@watson.ibm.com>
Date: Thu, 27 Jul 2000 14:25:33 -0400
Message-Id: <200007271825.OAA27320@alpha.watson.ibm.com>
To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>

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.

By moving our <Restrictions> and <Sequence> tags out of <SignedInfo>,
we now have to:

- send two elements, <SignedInfo> and <SignatureProperties> to the

- hash <SignatureProperties>

- insert that hash into <SignedInfo>

- hash <SignedInfo>

- sign that hash

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.

> Date: Fri, 14 Jul 2000 15:02:09 -0400
> From: "Joseph M. Reagle Jr." <reagle@w3.org>
> At 01:45 PM 7/14/2000 -0400, Ken Goldman wrote:
>  >In FSML, we have something similar to the <disclaimer> called
>  >signature restrictions.  For example, a signing token, possibly
>  >qualified by a signer login and password, might be constrained to sign
>  >purchase orders but not checks.
>  >
>  >What FSML does (in DSIG terms) is add a <Restrictions> tag to
>  ><SignedInfo>.  When the token receives the <SignedInfo> element for
>  >hashing and signing, it will reject the element if the <Restrictions>
>  >value does not match its internal rules.
> Hi Ken. I would argue that your stated use is syntactily invalid with
> respect to the content model as given by the DTD/schema (and I'm pushing
> that we be cognizant of this fact) and also semantically. (This is one
> reason why thinking in terms of a Data Model (via RDF) can be a good thing.
> [1]) 
> SignedInfo is merely a collection of References with two properties:
> SignatureMethod and C14NMethod. Placing other semantics in there can be
> dangerous. The purposes that you speak of seem much more appropriate to
> SignatureProperties. (Have you considered this?) 
> Syntax and semantics are not the same thing, but they obviously are closely
> related and in this instance we can use constraints on the syntax to also
> constrain the ability to make semantic assertions within our specified
> structures. Of course, one could place a similar corresponding statement in
> a Signature Property (invalid on Tuesdays) but that CLEARLY represents that
> this is a TRUST decision and has nothing to do with the signature structure
> nor its Signature Validity.

Ken Goldman   kgold@watson.ibm.com   914-784-7646
Received on Thursday, 27 July 2000 14:25:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:34 UTC