RE: [dss] Simplifying Verification (was: Re: [dss] Is a single <Schema> element adequate?)

["Edward Shallow" <ed.shallow@rogers.com>]

Wow !!!

   This is quite the departure from our current version of the protocol. I
have to wade in because I was largely responsible for the introduction of
the "Document Validation" model you describe. This approach was largely
motivated by ease of use concerns I had concerning our clients, as well as
the nature of signed XML content and what your typical DSS-enabled
"Validation Authority" would have to deal with.

   I have already got the "signature in document" validation working in both
escaped and non-escaped modes on the server and did not find it terribly
difficult. Now this might be symptomatic of the crypto library I am using. I
cannot speak for the others. Now granted I am doing quite a bit of XPath
searching and node splicing, but that's just XML. Simply including DTD
fragments in front of InputDocuments is resolving my Id problems, and
Reference chasing is a non-issue. I disagree with your comment " ... this
answer means nothing to the client unless the client re-creates the steps
the server followed ...". Either all signatures with their references verify
or they don't. The EPM profile has also made provision to verify particular
signatures within documents as well.

   If you want to simplify the "Document Validation" model, I would rather
you considered restricting InputDocuments to 1 in those scenarios instead of
throwing it out of core alltogether. This would remove a lot of your
perceived complexity.

   We also can't ignore the delay on things this would inevitably cause.

   As for the opaqueness issue, I think we are driving a tack with a
sledge-hammer, and the cure is turning out to be worse than the symptom. I
find little problem with the "Atom" approach cited on the list
http://www.oasis-open.org/apps/org/workgroup/dss/email/archives/200504/msg00
032.html   

   Perhaps you could send me a "document validation" scenario which you
believe creates this server-side complexity.

Ed

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: May 15, 2005 11:52 PM
To: dss@lists.oasis-open.org
Subject: [dss] Simplifying Verification (was: Re: [dss] Is a single <Schema>
element adequate?)

Tommy Lindberg wrote:
> Hi Trevor -
> 
> 
>>I think the possible solutions are:
>>1) go back to using <DTD>
>>2) add multiple <Schema>
>>3) not support server resolving <ds:Reference>s
>>
>>I'd vote for 3.
> 
> 
> Given the above options, I'd support 2.  The update would be minimal, 
> involving a multiplicity change, the only downside being somewhat 
> bloated payloads.


True, (2) is a smaller spec change.  However, the more I look at this
feature, the more I think we should remove it.

Below is an explanation of how verification works in different "modes". 
  I argue that some of these modes don't belong in the DSS core, and we
could simplify the core by shifting them to profiles.

(This is re-opening settled issues.  I'd like to summarize them again, since
my understanding has grown, and since implementation experience is causing
us to revisit them).


Sorry for the length!


Separated and colocated modes
------------------------------
To verify a signature, the server needs to match the <ds:Reference> elements
inside the signature with the XML elements they point to.  The simplest way
this happens is when the signatures and what they point to are "separated":
  - The client sends a request containing:
    - <ds:Signature> inside <dss:SignatureObject>
    - Input Documents inside <dss:InputDocuments>
  - The server extracts the <ds:Reference>s from the signature
  - For each reference, the server looks for a matching Input Document

However, we also allow the signatures and what they point to to be
"colocated" in one of two ways:
  1) The pointed-to XML elements can be enveloped inside the <ds:Signature>
(itself inside the <dss:SignatureObject>)
  2) The <ds:Signature> can be enveloped inside an Input Document (itself
inside the <dss:InputDocuments>).  In this case, a <dss:SignaturePtr> is
placed inside <dss:SignatureObject>.

In the colocated scenarios, we mandate that the server must be able to
evaluate <ds:Reference> URIs containing null URIs and barename XPointers
against the enveloping element.

Why we have different modes
----------------------------
Why do we have both "separated" and "colocated" ways of doing things? 
The separated approach is capable of handling any signature.  By treating
the <ds:Reference> URI opaquely, it avoids issues of the server searching
for signatures, or resolving URIs by evaluating XPath/XPointer expressions.
However, it requires the client to do the work of locating signatures within
documents, resolving <ds:Reference>s, and extracting the signature / Input
Document elements so they can be passed separately.

The "colocated" approach allows simpler client-side handling of XML
documents containing enveloped signatures or consisting of enveloping
signatures - the client just sends the entire XML document.  The server
searches for signatures to verify (if necessary), then resolves the
<ds:Reference>s.  However, for the server to resolve the <ds:Reference> URIs
containing null URIs and barename XPointers, in the general case, the client
must indicate to the server which elements in the enveloping element contain
ID attributes.

So with the "colocated" approach, the client has to transmit (or pre-arrange
knowledge of) schemas, which the server must be able to evaluate on the fly
(in addition to locating signatures, and supporting these different modes in
general).  Thus the colocated modes add a lot of complexity to the protocol
and to server processing.  Also, in many scenarios the client knows where
the signature is located, and will have to resolve the <ds:Reference> URIs
anyways to know what the signature covers.  In these scenarios, the
"colocated" approach doesn't save the client much work.

Colocated mode as "document validation"
----------------------------------------
The colocated approach is nice for clients who are using DSS not so much as
a "signature validation service", but as a "document validation service".
These clients can use a profile where they send an entire XML document to a
server, get back a good/bad response, and then process the document
contents.  If the server knows the document type beforehand, then much of
the complexity of colocation goes away (the server knows exactly where to
look for a signature and how to resolve <ds:Reference>s).

So "document validation" has value.  But it sits uneasily with the
"signature validation" functionality of DSS:
   - Trying to generalize "document validation" to work without pre-arranged
knowledge of the document type results in complicated and unnecessary server
processing.  (In other words: if the server searches for signatures, and
then searches for whatever <ds:Reference>s are matched, and then says
"good", this answer means nothing to the client unless the client re-creates
the steps the server followed to find the signature and references.  And if
the client was to do all that, he could have just used "separated"
processing).
  - It makes the verification protocol asymmetric with the signing protocol.
The signing protocol is not a "document creation" protocol that takes any
XML document on input and produces a somehow-signed version on output.  The
signing protocol takes specific instructions about what exactly to sign and
produces a signature.  Similarly, you would expect the verification protocol
to take instructions on what exactly to verify.

Removing document validation from core
---------------------------------------
So without questioning the usefulness of document validation, I question
whether it should be part of the DSS core.  We could eliminate it and make
Verify processing much simpler:
  1) All pointed-to XML elements must be in <dss:InputDocuments>
  2) The <ds:Signature> must be in <dss:SignatureObject>

Then we would have no server searching for signatures, handling multiple
signatures at once, resolving references, or evaluating schemas.

Adding document validation as a profile
----------------------------------------
Where would this leave document validation?  Perhaps we should have a
document-processing profile of DSS that operates on full XML documents,
instead of signatures.  This profile would assume the server already has
knowledge of the document type and the steps needed to sign/verify it.

This profile would have to substantially abuse core:  Signing would return a
full document, not a signature (and might add multiple signatures to the
document, or transform it in different ways). 
Verifying would take a full document, not a signature (and might verify
multiple signatures and different aspects of the document).  However, the
profile could re-use the optional inputs and outputs.  Anyways, I'd rather
have a profile abuse core then jamming all this into core itself.


Well, this is lot to digest.  If we want to get more implementation
experience before making big decisions like this, that's fine with me...


Trevor







---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php