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

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

At 12:59 03/12/2003 -0800, Trevor Perrin wrote:
>
>
>[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-s
pec-wd-07.pdf
>http://www.oasis-open.org/committees/download.php/4360/oasis-dss-1.0-core-s
pec-wd-07.doc
>?]
I am using the last one... well, what I will do is to download it again and
then check it once more
time.

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

Good question...I have not checked it... I will try to find out...
>
>
>
>>
>>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?
>
I see.... I have got it. The funny thing is that the informational RFC  3001
" A URN Namespace of Object Identifiers" specifically defines mechanisms
to define urn namespaces baded on the OIDs!!, which means that somehow
we can see different alternatives for doing things.
Well, I do not know... one could think that we are trying to identify
object types 
(different types of signatures) and as each one has a different OID, one
could use
the RFC 3001... on the other side one could think that the object is
defined in a
specific RFC and then follow RFC 2648 ... 
Is SAML using it to identify specific data types or specific RFC (ie
documents)?




>
>
>>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".
>
Agreed

>
>
>
>
>
>
>
>
>
>
>
>
>
>>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.
>
I would say that in this way the fact that one goes in the request and
that the other appears in the response would be explicit.

>
>>#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.
>
Much better, indeed. Agreed.

>
>
>
>>#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:
>
OK.. yes it looks like a cut and paste problem :-)

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

Your suggestion is that we should define a URI set 
identifying all the standardized XAdES forms, for instance.
Then if some service discovers that its environment requires
a form that is not standardized (a different combination of 
attributes), then the service itself can define a different URI
for THAT specific non  standardized form... is that what
you mean? If so I would tend to agree (it would certainly 
put less complexity in the protocol)

Regards

Juan Carlos.

>etc..
>
>
>Trevor 
>