[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] Comments on version 7 of the core document
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]