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

[Trevor Perrin <trevp@trevp.net>]

Hi Karel,

Thanks for these comments.  Responses inline -


At 09:52 PM 4/2/2004 +0200, Karel Wouters wrote:
>Hi all,
>
>some pseudo-editorial comments to the Core Spec WD 17
>
>- line 353: elements -> attributes (according to xsd)

Good catch.


>- line 530: If it's mentioned in 1.d that the children of <DocumentHash>
>   elements are taken as "output" of this step, the distinctions in 2.d and
>   2.e don't have to be made.

As it stands, Step 1 only applies to <Document> elements, not 
<DocumentHash> elements.  We could change that, but I'm not sure that 
re-organization would be worth it.


>- 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?


>- 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?



>- line 1140: creationTime attribute value
>   -> CreationTime (element) value)

Yes.


>- 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?


>- line 1172-1176: tstInfo->TstInfo, policy, errorbound and creationtime
>   are elements, not attributes

Yes.



>- the .xsd file: I had to change 2 things to load it into XMLSpy:
>   * The dss namespace declaration:
> 
>xmlns:dss="http://www.docs.oasis-open.org/dss/2004/04/oasis-dss-1.0-core-schema-wd-17.xsd";
>     -> xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema"

You should change the targetNamespace instead.  Sorry, I messed that 
up..  it'll be fixed in the next version.


>   * The SAML namespace import:
>     schemaLocation="http://www.oasis-open.org/committees/download.php/3407/
>     oasis-sstc-saml-schema-protocol-1.1.xsd"
>     -> 
> schemaLocation="http://www.oasis-open.org/committees/download.php/3408/
>     oasis-sstc-saml-schema-assertionl-1.1.xsd"
>   (I'm not an expert in these things, so don't ask me why :)

Yeah, I guess that's better... don't ask me why either.


>That's it for the moment;
>I'm also planning to make some constructive remarks on how to embed
>linked-timestamps into DSS. To be continued.

Cool.  You should maybe talk to Dimitri, and see about making a profile for 
this.


Trevor