Re: AW: AW: [dss] Comments on DSS Core Protocol WD 26

[Trevor Perrin <trevp@trevp.net>]

At 01:33 PM 10/1/2004 +0200, Gregor Karlinger wrote:
> >
> > I don't know DTDs enough to assess this.  Won't schemas be larger and
>more complex?  Do other people want to switch to schemas?
>
>[Gregor]
>Yes, but also more powerful. And - Schemas are namespace aware whilst DTDs
>are not - the reason why the example shown above does not work with DTDs.

People agree, we'll change to schemas.


> > (personally, I think having the server process schemas and evaluate
> > <ds:Reference> Xpointer expressions is too much.  I'd prefer to remove
> > this, and have the client always specify exactly what needs to be
> > verified.  The client will always know this - if the client doesn't know
> > what's being verified, how would it know what the verification results
> > mean?).
>
>[Gregor]
>I think that the client often only knows that there is a signature over
>something, and that the server should verify the signature and then tell
>the client what data was signed by the signature.

I think the client usually knows that it wants to verify a particular 
signed document.  The case where the client just wants to verify a 
*signature*, regardless of what it applies to, seems weird to me.  I wish 
we weren't expending so much effort and protocol complexity on it.  That's 
just a personal gripe, though...


> > A client can always construct a <ds:Manifest> element on its own, and
>send it as an Input Document.  As spec'd, the protocol doesn't help the
>client create a <ds:Manifest>, but the client can do it manually if he wants.
>So I'm not convinced we need to add anything to core, for this.
>
>[Gregor]
>In order to create a manifest the client must compute transform results
>and hashes itself. I guess that is not the stuff the client wants to do.

In that case, there could be a profile that support better server-side 
manifest handling.  At our last meeting the consensus on this was "Core 
should be left as is - client can make use of future profiles or do it itself."
http://www.oasis-open.org/apps/org/workgroup/dss/download.php/9394/DSS%20TC%20Minutes%202004-09-20b.txt


>[Gregor]
>I meant a null URI by itself (<dsig:Reference URI="">) as well. I was
>thinking of combining the null URI with an XPath or XPath2 transform (not
>using an Xpointer), which is the only way to select parts of an XML
>document if you (1) do not want to use ID refs (see above) and (2) do not
>want to use Xpointers (since they are an OPTIONAL feature of XMLDSIG,
>whereas XPath transform is RECOMMENDED).

Yes, we need better support for this.


> > >
> > >This does not help the client a lot. For detached signatures it must
> > parse the signature itself in order to resolve the referenced 
> documents. Not
> > >very comfortable ... Shouldn't you face this issue at least with an
> > >optional input that tells the service that it should resolve missing 
> input documents?
> >
> > I don't think so:
> >   - seems a rare case
> >   - lots of security issues:
> >     - server must have net access
> >     - client could send a "file:" URI or otherwise try to get the server
> > to access something the client shouldn't
> >     - URI content could change between when client checks document and
> > when server signs it
> >     - client could use the DSS server to probe or attack the URI-located
> > server; or that server could probe and attack the DSS server
> >
> > We decided against <DocumentURI> for these reasons (in the Nov. 3
> > meeting).  Admittedly, an optional input is lower impact.  Still, I
> > personally don't see enough value.
>
>[Gregor]
>All the problems you mention can be solved technically by the service.

At a cost in server complexity and reduced security.


>  I
>don't argue that every service must support that feature; but if you do
>not even provide an optional input, you exclude a large (and from my point
>of view widely used) class of XML signature. Putting the load of resolving
>the URLs on the client is not practical for the reasons I have already
>told (client must analyze the siganture). XMLDSIG was designed to use the
>mechanisms of the web, and URLs are a very important mechanism, aren't
>they?

We don't exclude that class of XML signature.  We simply require the client 
to retrieve the documents from the web, and present them.

I understand that putting it in as option doesn't force profiles to adopt 
it, but it tempts them to, and forces everyone reading the document to 
expend effort understanding and evaluating the mechanism.  So I still vote 
to leave it out.


> > I'm not talking about endless recursions either.  But multi-level
> > manifests
> > are discussed in XML-DSIG, so a proposal for handling manifests should
> > address them.  It would be nice if we could have WhichReference refer to
> > the <ds:Reference> through some Id or something, whether it's inside a
> > <SignedInfo> or <Manifest>, but I don't think that works.  Since your
> > proposal only handles a limited form of Manifest, I'm not in favor of
>it.
>
>[Gregor]
>Limited, but handling (in my opinion) the most important form. Isn't it
>better to have limited support rather than none?

We have limited support, it just requires client work.  I think it would be 
better to have server support be more complete, and be in a profile.


Trevor