Re: Valid XML and Schema Normative?

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
  card

- 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