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

[Trevor Perrin <trevp@trevp.net>]

Gregor,

Thanks for this excellent review.  I'm not sure if or when we want to 
update the Committee Draft, but I'll respond to your comments on the 
assumption there will be a next version sometime...


At 09:15 AM 9/9/2004 +0200, Gregor Karlinger wrote:
>All,
>
>please find below my comments on the DSS Core Protocol WD 26. I doubt that
>I am still member of the dss list, so could you please subscribe myself
>again?
>
>1. lines 278-282
>
>It would be useful if not only DTDs were supported for supplying grammar
>information, but also XML schemas. More and more grammars are written as
>XML schemas only, so the client would need to write DTDs in order to get
>fitting answers from the DSS.

DTDs only need to be transmitted with Verify Requests in the case where the 
client is not indicating which Input Documents the signature covers, but 
expects the server to deference the <ds:Reference> URIs.

This puts a lot of burden on the server, so hopefully it's not the common 
case.  Anyways, in this case the client needs to indicate ID 
attributes.  We chose DTDs since they allow clients to indicate ID 
attributes in a relatively simple way (i.e. the client doesn't need to 
prepare a DTD/schema covering everything in the document), and are 
supported by some tools like xmlsec.

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


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


>3. lines 649-659
>
>Why is there an optional input <AddTimestamp>? Should'nt a timestamp be
>treated as every other signature property, i.e. as an optional input
><Property>?

That requires the client to know the exact name of the Property.  Saying 
<AddTimestamp> is vaguer, and leaves it up to the server to determine a 
time-stamping technology and implementation.


>4. lines 684-761
>
>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.

How exactly would this work?  In theory you could have Manifests pointing 
to Manifests and so on.  I'm not aware of the use cases for Manifests, and 
people in this group haven't been clamoring for them.  So I'm leery of 
adding additional complexity for this.


>5. lines 842-851
>
>It is very likely that the enveloping signature refers to the enveloped
>document (which will be integrated into a dsig:Object) by means of an ID
>reference. But in order to achieve this, it is necessary to allow the
>client to define the name of the dsig:Object's ID attribute. I suggest
>to add an "IdAttr" to the <EnvelopingSignature> element.

The client could refer to an ID of the enveloped document, instead of 
referring to an ID of the <ds:Object> that contains the enveloped 
document.  But I agree it's a nice idea, and doesn't hurt anything.


>6. lines 920-931
>
>It is not mentioned what the DSS should do if the Xpath expression of the
><SignaturePtr> selects more than a single ds:Signature element. I suggest
>that the DSS should do the same as if the <SignatureObject> was omitted,
>i.e. to verify each ds:Signature.

Sounds good.


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


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


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


>10. lines 1018-1019
>
>The sentence should be more constraining, e.g. "Otherwise, if the CMS
>signature is enveloping, it contains its wn input data, and there MUST NOT
>be an input document present."

Okay. (for anyone reading along: this is a text clarification, not a 
substantive change)


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


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


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


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


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

We do the same by omitting the URI.


>16. lines 1294-1297
>
>Why must there be a <ds:reference with an omitted URI attribute? I fear
>that I did not get the message about how the <ds:Reference>s must be
>constructed in order to conform to this spec.

The <ds:Reference> with an omitted URI is the one containing the <TstInfo>.


>17. lines 1334,1338
>
>The Content-Type header should be either "application/xml" instead of
>"text/xml", of the spec should give a hint that the charset attribute must
>be used if the content encoding is not US-ASCII. (Setting the Content-Type
>to "text/xml" (without using the charset attr.) and providing a XML
>document with an encoding other than US-ASCII is invalid since the text/*
>mime type
>has US-ASCII as default char encoding; differently application/* has no
>default encoding, rather the encoding is defined by the content).

I was following XML-RPC.  I don't think it's invalid.  However, after 
looking at RFC 3023, I agree that application/xml is preferable.


Trevor