Re: [dss] Comments on version 7 of the core document

[Trevor Perrin <trevp@trevp.net>]

Hi Juan Carlos,

At 05:14 PM 12/3/2003 +0100, Juan Carlos Cruellas Ibarz wrote:

>Trevor,
>
>Below follow some comments on the version 7 of the core.
>I have identified the section number and the line(s) number.
>Just comments to sections 1 to 4 (included) come here....
>I will send comments as I progress throughout the rest of the document
>
>#1 Section 2.4.2. Line 382.
>Should not the attribute "MimeType" have use="optional"?

I agree.  It appears that MimeType isn't important to XML-DSIG Basic 
Processing, but it might be used by some other type of signature, so we 
should at least leave it in.

[my line numbers aren't the same as yours, but your comments are based on 
the latest draft.  I wonder how that happens.  Are you looking at one of 
these -
http://www.oasis-open.org/committees/download.php/4358/oasis-dss-1.0-core-spec-wd-07.pdf
http://www.oasis-open.org/committees/download.php/4360/oasis-dss-1.0-core-spec-wd-07.doc
?]



>#2 Section 2.5 Line 412.
>The prefix tst (tst:Timestamp) should appear defined in the
>namespace declaration at the begining of the document, in
>section 2.1.

Agreed.

(also, the Timestamp schema includes the DSS core schema, to get the 
dss:NameType element.  Are circular schema includes allowed?)



>#3 Section 2.5 Lines 446, 417.
>I understand that we identify the type of  signatures
>by an URI... that we define by ourselves.... in section 7.2.1 only
>appear URIs for XMLDSIG and CMS.
>Just one question and one request:
>
>Question: are the URI for the CMS derived from the OID as
>suggested in a RFC that instructs on how to derive URIs from
>pre-existing OIDs? If not, I think that we should follow it because
>in fact, the CMS HAS a UNIQUE AND PERMANENT identifier
>that is its OID, and the URI should be aligned with it.

These URIs are not derived from OIDs.  They're derived according to RFC 
2468, "A URN Namespace for IETF Documents".

SAML also uses IETF URNs like this.  Could we stick with these URIs and 
just add a reference to RFC 2468 in section 7?



>Request: I think that we should also provide URIs for:
>The signature defined in ETSI 101733, based in CMS.
>A PKCS#7 signature.

****


>#4 Section 2.6. Lines 464 and 468.
>Should not say "Options MAY appear..." and
>"Outputs MAY appear:...." respectively?

According to RFC 2119, MAY means "an item is truly optional".

This isn't describing optional behavior - but we could say something like 
"The server MUST be able to handle outputs appearing in any order within 
the <Outputs> element".



>#5 Section 2.7. Lines 502 and 504.
>What about substituting
>"The request could not be performed...."
>by
>"The request could not be satisfied...."

Agreed.




>#7 Section 3.4. Line 581
>What about substituting the title by:
>"Optional Inputs and Outputs" ?
>This would be more in line with our
>name change.

Agreed.



>#8 Section 3.4.8
>I think that the element ds:SignedReference in the
>contents of SignedReferences MUST have  a maxOccurs="unbounded".

Agreed.


>In its current content definition, there is only one ds:SignedReference and
>it is against the text in line 656.
>In addition the "minOccurs="0" MUST     be deleted: if there are no
>SignedReference at all, why to add the <SignedReferences> element?

Agreed.



>#9 Section 3.4.10
>
>This section introduces a behaviour that perhaps could be anticipated in
>section 3.3.2.
>Would it be worth to anticipate such a behaviour in section 3.3.2? Just
>asking.

Agreed.  I'll add text to 3.3.2 mentioning that the client can also offload 
producing the Enveloped Signature to the server, if the server supports the 
<SignaturePlacement> option.




>A second comment. What about to phisically separate the parts of the schema
>that
>come in the request and the parts that come in the answer? Just for
>avoiding any kind
>of confussion. The text could be something like:
>
>The <SignaturePlacement> element would appear as part of the <SignRequest>.
>Below
>follows the schema definining its contents:
>
>.....
>
>In reaction to the presence of a <SignaturePlaceement> within the request,
>the server
>MUST include the <DocumentWithSignature> element within the <SignResponse>
>element.
>Below follows....
>.....
>
>Or something like that.

Do you think that's better?  I don't see a big difference either way.


>#10. Sections 4.5.1, 4.5.2 and 4.5.3
>They contain the schema definition of ServiceProfile, ServicePolicy and
>ClaimedIdentity.
>But they had been already defined in 3.4.1, 3.4.2 and 3.4.3. I would
>suppress the XML
>schema pieces, but add some text indicating that these elements have the
>structure
>already defined in the aforementioned sections.

Frederick suggested moving them into the "Common Protocol Structures" part 
of the document, in a new 2.8.  I think that's a good idea.




>#11 Section 4.5.8. Line 925.
>The reference to XKMS is section 5.1.8, not 5.18.

Yes.



>#12. Section 4.5.8. Line 932.
>I think that there is a / character closing the element
>ReturnProcessingDetails.

Yes.



>#13 Section 4.5.11.
>I think that this element requires further refinement.
>First, the text seems to clearly indicate that the only way of updating a
>signature
>is by adding a time-stamp.

ooh.  I think that's a copy-and-paste mistake.  I'll change it to reflect 
that this element can be used for the variety of things you mention:

>  When I am thinking of updating I can also think of
>things like incorporating all the material that the server has used for
>verification
>(certpath, crls, ocsp answers, and of course any time-stamps that it can have
>requested....). I am, of course, thinking in signatures that can "grow" by
>incorporation
>of additional infos, like XAdES.
>
>Second, if this is accepted, then the client must be able to instruct the
>server on
>WHAT specific update it wants...If the schema is kept unchanged, the URI
>will have
>to identify some specific signature form, ie, some signature with
>additional data
>predefined somewhere else... for instance some of the XAdES forms..
>I would suggest to have an additional optional element that would allow the
>client
>specify what it wants the server add to the signature by enumeration.... I
>am not
>saying that this element must be defined in the core, it can be part of a
>profile.
>So what about adding an element AnyType that would allow for that?

Can't this be handled through the URI?

For example, you could have different URIs like:

urn:whatever:xades-c
urn:whatever:xades-x
urn:whatever:xades-xl

etc..


Trevor