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

Re: Understanding what Signed XML is used for - Was: Re: importi

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Mon, 02 Aug 1999 15:01:11 -0400
Message-Id: <3.0.5.32.19990802150111.00a422f0@localhost>
To: "tog" <todd.glassey@www.meridianus.com>
Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
At 09:04 AM 7/30/99 -0700, tog wrote:
 >Yes, but knowing the totality of the use models tells you how deep the
water
 >potentially is, and right now we don't know this.

Agreed, [1]

    4. Document the WG's position on signature semantics with a
       non-standards-track document. At the Chair's discretion the WG may
       develop a (small) set of signature semantics. Such a proposal
       would define common semantics relevant to signed assertions about
       Web resources and their relationships in a schema definition ([32]
       XML/[33]RDF) or link type definition ([34]XLink).
        [1] http://www.w3.org/Signature/charter-19990624.html
    
 >>         2. Punting promotes design generality.
 >
 >What do you mean by "Punting"
 
Definition (3,4) of [2]

punt /v./ 

[from the punch line of an old joke referring to American football: "Drop
back 15 yards and punt!"] ... 3. A design decision to defer solving a
problem, typically because one cannot define what is desirable sufficiently
well to frame an algorithmic solution. "No way to know what the right form
to dump the graph in is -- we'll punt that for now." 4. To hand a tricky
implementation problem off to some other section of the design. "It's too
hard to get the compiler to do that; let's punt to the runtime system." 
[2] http://www.journalism.wisc.edu/jargon/jargon_30.html

 >> All of those things that you spoke of are difficult problems even if you
 >> think they can be solved trivially by adding an attribute in the
 >sig-block,
 >> there are many many ways to do them incorrectly. [1]
 >
 >And this is ecactly why in the PKI world the "use model" (Applicability
 >Statements) are so powerful. becuase if we don't set the scope of the
 >usefull envelope of our technologies, the implementors may (read as "will")
 >try to do stuff that is inherently broke and we wind up looking like fools
 >then for not telling them they couldn't do "XY and Z" without "A" too.
 
Understood, but many of these things you spoke of will be predicated on the
data-model/inference/trust-engines of capability/policy/statement/assertion
systems that we have no control over. We are merely signing those things.
We, in general, will not be able to tell people what sort of trust
applications they can design, but we need to make sure we use a data model
such that "signature validity" can be cleanly applied over any trust
semantic. For a lot of these critical applications (packages, time stamps,
etc.) thinking them through as a test of generality of our design is
probably a good idea, but coming to a consensus on a design solution for
those problems is not in the critical path/charter of this WG. (Though we
can certainly re-charter to address these issues in the second phase.)


_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/
Received on Monday, 2 August 1999 15:01:21 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:07 GMT