OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

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