Comments on DSS Core Protocol WD 26

["Gregor Karlinger" <gregor.karlinger@cio.gv.at>]

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.

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.

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

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.

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.

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.

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.

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.

9. line 975

I guess it should read "Upon receiving this *minor* code ...".

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

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.

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?


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.

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

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

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.

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


Liebe Gruesse/Regards,
---------------------------------------------------------------
DI Gregor Karlinger

Stabsstelle IKT-Strategie des Bundes/Bundeskanzleramt
Federal Staff Office for IT Strategies/Federal Chancellery

Post/Mail: Ballhausplatz 2, 1014 Wien, Austria
Besuch/Visit: Wagramer Straße 4, 1220 Wien, Austria

Newsletter: http://labs.cio.gv.at/newsletter/ 
mailto:gregor.karlinger@cio.gv.at          http://www.cio.gv.at
fon +43 1 53115 6163 fax +43 1 53109 6163 mob +43 664 610 45 44
---------------------------------------------------------------

smime.p7s