[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: More comments on Gregor's suggestions
Comment on some of Gregor's points ...
>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.
This is another example of profiles being obliged to support base XMLSig
capabilities due to the absence of support in the core. BTW, templates would
clearly have no problem with this. Again, as I mentioned in a recent post,
the core should at least make a semantic statement as to non-support in this
area. Unfortunate, but true.
>>Actually, it should be "<foo>bar<foo>". Could you suggest a
clarification?
You mean <foo>bar</foo>.
>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.
I vote for the inclusion of this suggestion in core prior to next release. I
see no advantage in postponing this.
>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.
Déjà vu on this one. The possibility of a multiply signed document with
explicit Xpath selection should be clarified in the text. We have some
amount of verbage on this now, but it doesn't cover this scenario.
>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)
>>The need for clarification here makes sense, as does the suggested text.
> * 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
allthis.
>> Also, we can always use the dss:Result/ResultMessage to return
>> free-formtext, so I'm not sure how important it is to specify data
structures for allthe above.
Including this detail in ResultMessage is not only a good idea, but
something that should be more strongly encouraged in the core. All the
profiles are facing this same quandry. Wouldn't you like some consistency ?
>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.
Lots of clarification required here. In the CMS/PKCS7 world, the signature
being verified could have a SigningTime 1.2.840.113549.1.9.16.2.46 as well
as a timestamp token
1.2.840.113549.1.9.4.16.2.14
or even a content timestamp 1.2.840.113549.1.9.16.2.20, or even both. Which
one to return ? Is it 3rd-party OKed only if it is a timestamp token ?
Should the timestamp signature not be verified prior to returning the
timestamptokentime ?
>>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
>>somesimpler way.
Not sure simplicity is the only goal here, manifests were thought to be a
worthy contribution to XMLSig. Are we brushing it off ?
>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.
How so ? Either it is more explicitly qualified, or semantics states
something like ... The 1st reference is to <TstInfo>. Needs more clarity
here.
Ed
-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net]
Sent: September 14, 2004 1:47 AM
To: dss@lists.oasis-open.org
Subject: Re: [dss] Comments on DSS Core Protocol WD 26
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]