Comments on version 7 of the core document

[Juan Carlos Cruellas Ibarz <cruellas@ac.upc.es>]

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

#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.

#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.

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?

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


#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.

#8 Section 3.4.8
I think that the element ds:SignedReference in the
contents of SignedReferences MUST have  a maxOccurs="unbounded".
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?

#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.

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. 

This comment would also apply to all the sections where there are optional
Input and
their corresponding outputs, namely: 4.5.8, 4.5.9, 4.5.10, 4.5.11, 4.5.12


#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.


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

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

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



Regards

Juan Carlos.