[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] comments on Core Spec WD 17 & xsd
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. > > >- 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. BTW, there's another tiny inconsistency: <dss:Timestamp> vs <dss:XMLTimeStampToken> (capitalisation of the 'S') > > >- 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 ? Karel.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]