[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WG: AW: [dss] Comments on DSS Core Protocol WD 26
Sorry, I sent the initial mail from the wrong email account, so it did not
make it to the list.
/Gregor
-----Ursprüngliche Nachricht-----
Von: Gregor Karlinger
Gesendet: Freitag, 01. Oktober 2004 13:34
An: Trevor Perrin
Cc: oasis.dss ML (dss@lists.oasis-open.org)
Betreff: AW: AW: [dss] Comments on DSS Core Protocol WD 26
Trevor,
> -----Ursprüngliche Nachricht-----
> Von: Trevor Perrin [mailto:trevp@trevp.net]
> Gesendet: Samstag, 18. September 2004 10:43
> An: gregor.karlinger@cio.gv.at
> Betreff: Re: AW: [dss] Comments on DSS Core Protocol WD 26
>
>
> 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>
> >
[Trevor]
> >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?
[Gregor]
Yes, but also more powerful. And - Schemas are namespace aware whilst DTDs
are not - the reason why the example shown above does not work with DTDs.
> (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?).
[Gregor]
I think that the client often only knows that there is a signature over
something, and that the server should verify the signature and then tell
the client what data was signed by the signature.
> > > >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.
[Trevor]
> 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.
[Gregor]
In order to create a manifest the client must compute transform results
and
hashes itself. I guess that is not the stuff the client wants to do.
> > > >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...
> >
[Trevor]
> >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?
[Gregor]
I meant a null URI by itself (<dsig:Reference URI="">) as well. I was
thinking of combining the null URI with an XPath or XPath2 transform (not
using an Xpointer), which is the only way to select parts of an XML
document if you (1) do not want to use ID refs (see above) and (2) do not
want to use Xpointers (since they are an OPTIONAL feature of XMLDSIG,
whereas XPath transform is RECOMMENDED).
> > > >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.
[Gregor]
All the problems you mention can be solved technically by the service. I
don’t argue that every service must support that feature; but if you do
not even provide an optional input, you exclude a large (and from my point
of view widely used) class of XML signature. Putting the load of resolving
the URLs on the client is not practical for the reasons I have already
told (client must analyze the siganture). XMLDSIG was designed to use the
mechanisms of the web, and URLs are a very important mechanism, aren't
they?
> > > >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.
[Gregor]
See my comment on issue 2.
> > > >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.
[Gregor]
Limited, but handling (in my opinion) the most important form. Isn't it
better to have limited support rather than none?
> > > >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.
[Gregor]
Fine.
Best regards, Gregor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]