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

[Trevor Perrin <trevp@trevp.net>]

Gregor -

At 01:57 PM 9/17/2004 +0200, Gregor Karlinger wrote:
>[Gregor]
> > >It would be useful if not only DTDs were supported for supplying
> > >grammar information, but also XML schemas.[...]

[Trevor]
> > We probably don't want to support both DTDs and Schemas, cause then
> > servers have to handle both.

[Gregor]
>I understand the motivation behind this. However, there are documents that
>cannot be supported with this mechanism, like the following:
>
><test xmlns="urn:test">
>   <child xmlns="urn:foo" Id="child1"/>
>   <child xmlns="urn:bar" IdAttr="child2"/>
></test>
>
>Since DTDs are not namespace aware, you cannot support the grammar that
>tells the parser which elements could have ID attributes, with a DTD in
>this case. If you write
>
><!ATTLIST child
>   Id ID #IMPLIED
> >
>
>you cannot distinguish between child in the foo ns and the child in the
>bar ns, but you had to ...

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?

(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?).


> > >2. lines 570-571
> > >
> > >Is it realy intended that the server extracts the *text content* of
> > >XMLData,
> > >i.e. for example that <XMLData><foo>bar</foo></XMLData> results in a
> > >string
> > >"bar"? Or should it mean that the resulting string is
>"<XMLData><foo>bar
> > ></foo></XMLData>"? If the latter is true, then the sentence should be
> > >clarified.
> >
> > Actually, it should be "<foo>bar<foo>".  Could you suggest a
> > clarification?
>
>What about the following:
>
>"If the <Document> contains <XMLData>, the server takes the xml content of
><XMLData>, and converts it into an octet stream using [C14N]."

That may be better, let me look into this some more.


[Gregor]
> > >The DSS signing service has no support for creating a DSIG Manifest.
> > >There are several use cases where a client wants a Reference to be 
> added to a
> > >DSIG Manifest instead of SignedInfo. It would be easy to support this by
> > >adding a boolean "AddToManifest" attribute to the <SignedReference> 
> child of
> > >the <SignedReferences> optional input.

[Trevor]
 > How exactly would this work? [...]

[Gregor]
>If there exists at least one <SingedReference> optional input, the DSS service
>
>1. creates a dsig:Manifest and puts into it a dsig:Reference corresponding
>to each <SignedReference> optional input (instead of putting a
>dsig:Reference into the dsig:SignedInfo of the signature to be created.
>
>2. creates a dsig:Reference referring to the dsig:Manifest and puts it
>into the dsig:SignedInfo.

This can only create signatures of a specific form:
  - the signature has only a single top-level Manifest
  - the Manifest is not a multi-level Manifest

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.


> > >7. lines 933-934
> > >
> > >The sentence should read "If such an input document is not present, and
> > >the <ds:Reference> uses a null URI ("") or a null URI followed by a
> > >barename XPointer (e. g. "#foo"), the XPointer ...". With the current
> > >reading, a null URI is not included.
> >
> > It wasn't meant to include a null URI.  Is that a problem?  Would you
> > expect a null URI to invoke the searching behavior described in step
> > 1?  I'd kind of hate to tangle this logic even more than it is...
>
>If you do not support the null URI, you exlude a powerful class of XML
>signatures. If I do not want to work with ID references (for instance to
>overcome problems with resolving it if no grammar is availabe), I would
>use a null URI in conjunction with an XPath or XPath2 transform to select
>certain parts of the enveloping document.

Sorry, I meant a null URI by itself (without an XPointer) isn't 
supported.  Were you advocating we support that?


> > >8. lines  932-943
> > >
> > >The text does not say how the DSS should react if the <ds:Reference>
>uses
> > >a full URI, but no corresponding input document exists. I suggest that
> > the
> > >DSS should try to resolve the URI, at least for certain protocols like
> > >http or
> > >https. Otherwise the DSS client has to parse the signature in order to
> > >check what documents are referenced and to resolve the references to
> > these
> > >documents.
> >
> > If no corresponding input document exists, it should return the
> > ValidSignature_NotAllDocuments error code (see 4.4).  We should add text
> > in
> > Basic Processing that mentions this.
> >
> > I think resolving the URI is a bad idea - we don't want to mandate that
> > servers have Internet connections, and we don't want clients to expect
> > 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.


> > >9. line 975
> > >
> > >I guess it should read "Upon receiving this *minor* code ...".
> >
> > The text refers to the combination of major & minor code, so I think
>it's okay.
>
>OK, but it is not an *error* code.

Ah, good point, that should be changed.


> > >11. lines 1032-1039
> > >
> > >The paragraph should be more specific on what <ResultMinor> code the
>DSS
> > >should report if the optinal input >VerifyManifests> is present, i.e.
> > what
> > >is the <ResultMinor> code if there is a failing <ds:Reference> in a
> > >manifest.
> >
> > Presumably it should treat any <ds:Reference>'s within a manifest just
>as
> > if they were within the <ds:Signature>.  I can add text that clarifies
> > that.
>
>I do not think that this is a good idea since the processing model for a
>Manifest is different from that of a SignedInfo: If a SignedInfo Reference
>fails, the service may stop the validation processing without trying to
>validate subsequent References; If a Manifest Reference fails, the service
>must process subsequent References as well.

If the client wants to handle Manifest References differently from 
SignedInfo References, it can verify them on its own.  So I still think a 
server receiving <VerifyManifests> should just treat Manifest References 
like SignedInfo References.


> > >12. lines 1084-1126
> > >
> > >The dss:DetailType should be elaborated further. At least there should
>be
> > >a derived type the DSS can use if the Type attribute is set to
> > >urn:oasis:names:tc:dss:1.0:detail:Signature, providing the following
> > >information:
> > >   * Which signature (in case several signatures have been found)?

I strongly objected to multi-signature verify; the proponents of it agreed 
to keep error-reporting simple, it was sort of a compromise.  I really hope 
we don't start adding more complexity around it.


> > >   * What failed (signature or references)?
> > >   * If a reference faild, which reference failed?
> > >   * Is the failed reference in ds:SignedInfo or in a ds:Manifest? If
>the
> > >     latter, in which ds:Manifest?
> >
> > Not a bad idea, but it's not trivial to design something to carry all
> > this.  Also, we can always use the dss:Result/ResultMessage to return
> > free-form text, so I'm not sure how important it is to specify data
> > structures for all the above.
>
>Free form text does not allow automatic procesing.

I don't think we need automatic processing for those things.  If a 
signature verify fails that should've succeeded, researching why will be a 
manual process, so I think free-form text is fine.


>  Especially when the service processes a Manifest it is important for the 
> client to get these
>details in a automatically processable fashion (cf. my comment on the
>differences in the processing model above).

I'd rather keep the core simple, and say if the client has special 
requirements around Manifests, the client can process them himself (or you 
can do a profile spec'ing more sophisticated Manifest support; we have a 
notion of "Abstract Profiles" that can be mixed into other profiles, which 
lets us add new functionalities that didn't make it into core).


> > >13. lines 1132-1134
> > >
> > >The text does not say how the DSS should react if it cannot find any
> > >information on the singing time of the signature. I suggest that the
> > ><SigningTime> output should be extened with an option that indicates
> > >such a situation.
> >
> > I suggest that the server simply omits the <SigningTime> output.
>
>Fine as well, but it should be stated in the spec ;-)

Agreed.


> > >14. lines 1178-1206
> > >
> > >The <TransformedDocument> lacks support for manifest references. I
> > suggest
> > >to add an optinal attribute "WhichManifest" to the
> > ><RetrunTransfromedDocument> element. If the attribute is not set, the
> > >value of "WhichReference" refers to the <ds:SignedInfo>. If the
>attribute
> > >is used, its value refers to the particular <ds:Reference> in
> > ><ds:SignedInfo> that refers to the manifest. E.g, if I had
> > >
> > ><ds:Signature>
> > >   ...
> > >   <ds:SignedInfo>
> > >     <ds:Reference URI="foo">...</ds:Reference>
> > >     <ds:Reference Type="...#Manifest"
>URI=#manifest">...</ds:Reference>
> > >   </ds:SignedInfo>
> > >   ...
> > >   <ds:Object>
> > >     <ds:Manifest Id="Manifest">
> > >       <ds:Reference URI="bar">...</ds:Reference>
> > >     </ds:Manifest>
> > >   </ds:Object>
> > ></ds:Signature>
> > >
> > >and I am interested in the transformed document of the ds:Manifest's
> > first
> > >ds:Reference, I would use
> > >
> > ><ReturnTransformedDocument WhichManifest="1" WhichReference="0"/>.
> >
> > Manifests can point to manifests, so that doesn't work in the general
> > case.  Again, I'm not sure manifest support is worth adding, unless
> > there's
> > some simpler way.
>
>Again, endless recursions are not the thing I am talking about. But a
>Manifest directly referred to by a SignedInfo Reference *will be* widely
>used.

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.


> > >15. lines 1242-1246
> > >
> > >I suggest to mandate the use of the Type attribute in <ds:Reference> to
> > >indicate that the <ds:Reference> refers to a <TstInfo>. Then it is
>easier
> > >for a verifying engine to detect which <ds:Reference> of the timestamp
> > >refers to the <TstInfo>.

Never mind my previous comments, I was confused.  This seems reasonable.


Trevor