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

Re: Some possible rqmt/design points

From: TSG - Meridianus <Todd.Glassey@www.meridianus.com>
Date: Wed, 16 Jun 1999 11:51:13 -0700
Message-ID: <00bc01beb829$36e379c0$930aff0c@brick>
To: "Phillip M Hallam-Baker" <pbaker@verisign.com>, <david.solo@citicorp.com>
Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>, "XML Legal Filing" <leg-xml-l@gsulaw.gsu.edu>, "Ruven Schwartz" <ruven.schwartz@westgroup.com>
Some commentary to the group ...  I support Phillip's commentary regarding
the need to unambiguously bind the object's being signed to the signature
with the timestamp (if also required)...

BTW, There is a code model for a revised Digital Signature Blob and a method
of creating bounded objects in the bottom of this commentary, so if you have
interest look the whole response over

Any response are welcome!

Todd Glassey


----- Original Message -----
From: Phillip M Hallam-Baker <pbaker@verisign.com>
To: <david.solo@citicorp.com>
Cc: IETF/W3C XML-DSig WG <w3c-ietf-xmldsig@w3.org>
Sent: Wednesday, June 16, 1999 7:54 AM
Subject: RE: Some possible rqmt/design points


>
> >  Also, beyond the basic mathematics, I will continue to argue
> > that the decision to "accept" a signed thing is based on the rules of
> > the relying party, not the signer (although quite possibly dictated by
> > external agreement); hence the assertion of criticality by the signer is
> > misplaced.
>
> OK Dave, I accept the point that the interpretation of the work is
> performed by the recipient. I don't however accept that this means
> that the sender should not have the means to fully express their
> original intentions.
>
> The semantics 'If you don't understand X then you don't understand
> this signature' are pretty basic.

This is absolutely critical to the point of what you are trying to
accomplish with the XML document envelope. If you want a single use model
then the current mindset *may* work. But if the XML envelope is meant to be
be passed back and forth with its contents being altered or annotated on the
fly, then the current DigSig mindset is insufficient.

Otherwise the XML filing structures can realistically only represent "final
cut's" at douments and instruments.

>
>
> > On the practical front, the experience with criticality in X.509 has
> > been a nightmare.  Problems range from interoperability (I can't include
> > an extension/attribute with a critical flag unless I'm sure all RP
> > software will handle it)
>
> This is not a bug - it is the intention of the feature!

And it is also time (hitorical time that is) specific. What I mean is that
in these day's - i.e. June of 1999 AD, we are really still in what I refer
to as PKI's  'Summer of Love'; that is to say that  PKI systems and the
global ubiquity is just not there yet, but give it ten years and then try
and make this commentary.

>
> Unlike the traditional IETF projects signed XML will not be an
> arena where everything SHOULD interoperate with everything
> else.

This is a very porwerful statement and it is exactly accurate!. What it
really goes to say is "that the PKI world is both general purpose and
specific model based"  and not acknowledging that the two dualities exist is
tantamount to sucicide.

What the PKI core enablement 'is' are technological methods for
accomplishing certain process functions, what the XML and IOTP efforts
embody are, is uses of the core technologies, rather than the core
technologies themselves.

With this in mind, it is very important to be specific to the task at hand
and to realize that there are some models that may not fit under the general
purpose banner. They may need to be specific in their architecture and
process so that as Phillip so rightly points out, the use models are
specific to the task at hand, and not general purpose.

>
> I have an XML document in one hand which represents a Bill
> of Lading. Do I want that document to be accepted unquestioned
> by the application that handles Letters of credit?

No Way!

>
> The purpose of the signature attributes is to prevent
> a signature issued to one context being erroneously
> interpreted by another. See Bruce S's paper on protocol
> substitution attacks.

Absolutely! So the objects have to be identifiable as such .

>
>
> Unless it is possible to bind the context of the signature
> unambiguously to the signature we will encounter a whole
> rack of legal problems.

So here we are at the meat of the issue. The objects that are signed or
authenticated must be uniquely identifiable.

So lets talk about a potential methods:


1)    Make te DigSig tag an attrubute of general object classes and tags, so
that any tag's refernced object can bear a signature.

This enables the signing of any inline structures and also raises some other
interesting problems in and of itself. The concern of this as a general
purpose issue is based in it's not answering the "define the object" being
signed issue, but it could be useful in setting general policy and control
services, so it should be looked at.

2)    Create an Object Identifer tag.

This is the big win. That is to create a mechaninsm of defining a "bounded
object" as a persistant structure. We coined the term DAO for this, to mean
Digitally Authenticated Object. The what and how you authenticate the object
is also easily defined.

This is inherently simple since it essentially takes on the contenxt of the
HTMLconstruct
    <A NAME="yada yada yada">
almost.

We propose that to use a DAO you would do something like:

<DAO MetaObject_id, default signature services, timestamp requirements;
default policy state(s)>
    <Object Obj=a>
...
    <Object Obj=b Dependency_list; Policy List; Attribute Dynamics >
...
    </Object b>
...
    <Object Obj=c Dependency_list; Policy List; Attribute Dynamics >
...
    </Object Obj=c ObjSig=ObjectCsignature:ObjSigTimestamp>
    </Object Obj=a>

</DAO ObjASigBlob=ObjectAsig:timestamp; ObjBsigBlob=ObjectBsig:timestamp;
ObjCsigBlob=ObjectCsig:timestamp...>



Where:
    Dependency_list is the hierarchical attribute dependency's for this
object - this can be used to link MetaObject_id's in larger structures.

    Default signature services is the  default signature type for the
general DAO itself.

    Timestamping requirements is the timebase and audit model required by
the object;

    Default policy state, is a criteria defining the use model of the object
or any other user-defined policy features re: the use of the object

Note the use of the instantaneous signature embedded into the closing object
tag for Object "C". Also note that it is leveraged by the  Policy Vector so
that when any of the objects in it's Dependency_List are altered, it also
must be altered or the document finalization policy will not be satisfied
and thus the global signing will not be permitted.

This use model is seen as a key feature for building contracts and
negotiable instruments. It creates a sense of enforced traversal and can be
easily made though first-person models to indicate the transference of a
power of arttroney or intent of the transaction. Both gating  issues in any
third person processing models.

We may also want to add other indexes and linkages to external structures
and objects. These are likely use model specific and may not need to be in
the general case model.

in any event... there are about a bazillions ways to do this but we need
some object level signature control if we are to build reusable document
envelopes out of the XML tools.

BTW, how many people have looked at http://sunsite.berkeley.edu/Ebind/ the
Electronic Binding project at UC Berkeley. There is some good document
reusability mindset here and some it may bear transplanting into our garden.

As to the enabling of DigSig as an attribute, I would love to embed a
digital signature in the DocType Tag statement, so I support both of these
mindset's for using the Digital Signatures.

Just my 2 cents


Todd Glassey
Received on Wednesday, 16 June 1999 14:52:59 GMT

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