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

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

Trevor,

> Trevor Perrin [mailto:trevp@trevp.net]
> >Gregor Karlinger


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

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

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

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

OK.

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

I don't think that endless recursions of Manifests are a common use case
;-)
However a single Manifest referenced by a dsig:SignedInfo/dsig:Reference
is a use case (at least here in Austria in projects concering
E-Government). We treat those documents with Manifest references instead
of Signedinfo references, that should not render a signature invalid if
they are not available for some case.

Using the "AddToManifest" would work as follows: 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.

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

But only if the enveloped document root allows for an ID attribute.

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

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.

> >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 in-
put that tells the service that it should resolve missing input documents?

I am sure that there will be services that want to provide this feature in
order to ransom the client from this burden ;-)

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

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

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.

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

Free form text does not allow automatic procesing. 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).

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

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

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

Isn't this conflicting with lines 1242-1243: "There MUST be a single
<ds:Reference> element whose URI attribute references the <ds:Object>
containing the enveloped <TstInfo> element."

An omitted URI cannot reference something, can it?

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

/Gregor

smime.p7s