Re: [dss] comments on Core Spec WD 17 & xsd

[Trevor Perrin <trevp@trevp.net>]

At 09:56 AM 4/3/2004 +0200, Karel Wouters wrote:
>some additional comments inline
>
>On Fri, 2 Apr 2004, Trevor Perrin wrote:
>
>[snip]
> > >- line 547: Using C14N: isn't this the default behavior of XMLSig ?
> > >   I know the 'user' can override this default, but maybe it should be
> > >   mentioned that the default behavior is a MUST for this spec?
> >
> > The way I read 4.3.3.2 of http://www.w3.org/TR/xmldsig-core/, using C14N in
> > this case is mandatory.  So I don't think we're adding an additional
> > requirement, we're just re-iterating how xml-dsig applies here.
> >
> > Maybe we should add the phrase "In particular" to the start of this
> > sentence, and change "must" to "MUST", to make it more clear?
>
>the re-iteration made me wonder if this was something new, so it was
>confusing to me. Maybe just add something like "this is the default
>behaviour of an XMLDSig application.

I'll add "Following [XMLSig]" to the beginning of the sentence:

"These transforms should be applied as per [XMLSig] section 
4.3.3.2.  Following [XMLSig], if the end result of these transforms is an 
XML node set, the server must convert the node set back into an octet 
stream using Canonical XML [XML-C14N]."


> > >- Line 1100: "The <XMLTimeStampToken> element is of type
> > >   ds:SignatureType. Using ds:SignatureType allows conventional XML 
> Signature
> > >   implementations to validate the signature,"
> > >[...]
> > >   I don't know if an
> > >   ordinary XMLDSig implementation will be able to verify this, since
> > >   the <ds:Signature> element is replaced by <dss:XMLTimeStampToken>
> > >   (different element names, different namespace)
> >
> > Should we change the text to: "Using ds:SignatureType may allow
> > conventional...."?  Or do you have another suggestion?
>
>My suggestion would be just to add an extra level:
><dss:XMLTimeStampToken>
>  <ds:Signature>
>    ...
>  </ds:Signature>
></dss:XMLTimeStampToken>
>
>this makes it possible to pull the signature through a standard verifier,
>if the next issue is also resolved.

The <dss:Timestamp> element sort of already provides that extra level.  So 
if we're going to change things, we could also just change 
<dss:XMLTimeStampToken> to <ds:Signature> without adding anything new.



>BTW, there's another tiny inconsistency: <dss:Timestamp> vs
><dss:XMLTimeStampToken> (capitalisation of the 'S')

RFC 3161 spells it "TimeStampToken" so I think we were just following that.


> > >- line 1168: Omitting the URI from a reference. If the TstInfo can have an
> > >   ID, why not just refer to it? From the XMLDSig spec:
> > >   "If the URI attribute is omitted altogether, the receiving application
> > >    is expected to know the identity of the object.  For example, a
> > >    lightweight data protocol might omit this attribute given the
> > >    identity of the object is part of the application context."
> > >   I see two inconsistencies:
> > >   * this is not a light-weight implementation
> > >   * it's not possible to pull the signature through a 'standard'
> > >     verification program
> >
> > Good points, especially the 2nd.
> >
> > What I didn't like about including the ID is that if the timestamp is
> > included in a larger document, the ID might clash with an ID in the larger
> > document.  Though I guess this risk is negligible if we require it to be a
> > random string.
> >
> > So maybe that's not a big deal.  Anyone else have an opinion?
> >
>
>As I understand the DSS core spec, input documents are referred to by
>RefURI attributes of type xs:ID (line 552, WD17), so I guess using an ID
>to refer to TstInfo is more or less the same thing ?

RefURI is of type xs:anyURI, I think you mean RefId?

Anyways, you've raised 2 good points we'll need to settle on the next call 
(monday):
  - should we change <dss:XMLTimeStampToken> to <ds:Signature> to make it 
easier to validate with conventional implementations?
  - should we have the Timestamp reference the <TstInfo> via a fragment ID, 
instead of implicitly, for the same reason?


Trevor