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

[Trevor Perrin <trevp@trevp.net>]

Edward Shallow wrote:
> 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.

Do you handle everything in "4.3 Basic Processing for XML Signatures"?

The rules look complicated to me.  But I'll leave off arguing till I see 
how implementation / interop goes.


[...]
> 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.

That was too strong and not well-expressed, what I was trying to say:
  - If the server has prior knowledge of a document type, it can 
implement efficient, specific processing for it.  Call this "specific 
document validation".
  - However, the core specifies "generic document validation" - find all 
signatures in document, find all references, verify them.

- This is costly / complicated (search entire document for signatures, 
handle multiple signatures at a time, transmit XML schemas for resolving 
XPointer expressions, etc.)

- This is also not very useful -
  - When server has prior knowledge of document, it will use "specific 
validation", so "generic validation" is unnecessary
  - If client knows / needs to know / can find out where the signatures 
are in the document and what they cover, and is capable of basic XML 
manipulation, then it could use "signature validation" instead of 
"document validation".
  - I think above are most common cases.


>    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.

I don't think it would remove much - there would still be searching for 
signatures, multi-signature validation, signatures-inside-documents and 
documents-inside-signatures, and resolving XPointers.


>    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   

On the contrary, I think encoding is a "sledgehammer" - all we need to 
do at the server is canonicalize the XML without its DSS-inherited 
namespace context.  Opaque-encoding and re-parsing is a roundabout way 
to do that.  A processing rule that just says "don't canonicalize the 
DSS-inherited namespace context", which is what exclusive-canonical XML 
does, seems simpler and more elegant.

(Also, encoding doesn't address the issue of transporting the original 
namespace context.  For example, suppose you want to sign this fragment:

<abc:somexml id="whatever>
   blabla
</abc:somexml>

Which inherits namespace context:
  xmlns:xyz=something
  xmlns:abc=something else

The client would need to add these prefix declarations to the fragment 
before encoding.  That's basically the same amount of work as the 
re-declaration of namespace prefixes and InclusiveNamespacePrefixList 
that I'm talking about).

Trevor