[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: RE: FROM JUAN CARLOS: FIRST COMMENTS TO TREVOR SCHEMA
From Ed - (who I though was a member?) >From: "Edward Shallow" <ed.shallow@rogers.com> >To: "'Nick Pope'" <pope@secstan.com>, "'Trevor Perrin'" <trevp@trevp.net>, > <Cruellas@ac.upc.es>, "'Tim Moses'" <tim.moses@entrust.com> >Subject: RE: FROM JUAN CARLOS: FIRST COMMENTS TO TREVOR SCHEMA > >Nick, Juan-Carlos, Tim, and Trevor, (... please Post) > >As it pertains to "Options" handling, I am in complete agreement with >Juan-Carlos' quote below. I had originally categorized all the "Options" he >refers to below under "ProcessingOptions" for the same reasons. The >"Options" construct will likely be the prime focus of the core versus >extended profile differentiation. This, as Juan-Carlos points out, allows us >to isolate the base and extended handling required for profiling in a single >place. What is or isn't supported is largely evident from this single >structure (See my schema suggestion for base and extensions handling). >However, I do not believe we need a separate "Options" category for compound >operations. > >These terms that we throw around internally need not be exposed to the user. >Example: if adding a timestamp to a signature is required, then accommodate >it as such. Do not categorize the Options by how we happen to process them, >but rather from the perspective of the request itself. Again "What one wants >done". Requests that result in the service performing a compound operation >is the service's business. We need simply address the protocol request and >response element pre-requisites to allow the service to do its job. The >primary versus secondary verb should be evident from a well-chosen options >instance. > >Ed > >Excerpt from Juan-Carlos' lengthy post RE: Schema comments Aug 29th ... > >Quote ... > > Finally, just to comment again that I think that an approach where the >root element would have only one child "Options" containing different >children each one corresponding to different types of options is much >cleaner than having three root children related to different options.... > >... End Quote > >-----Original Message----- >From: Nick Pope [mailto:pope@secstan.com] >Sent: September 2, 2003 3:41 AM >To: Ed Shallow > > > >-----Original Message----- >From: Nick Pope [mailto:pope@secstan.com] >Sent: 29 August 2003 10:26 >To: OASIS DSS TC >Subject: FW: FROM JUAN CARLOS: FIRST COMMENTS TO TREVOR SCHEMA > > >Forwarding on behalf of Juan Carlos > >Dear Trevor, >I have been looking to your proposal. >In general, and for summarizing, I think that the structure that you propose >is far from the original structure that was initially worked out and agreed >during the f2f meeting, and I do not agree with the grouping of certain >elements. >The proposal that I submitted to you was aligned with that structure and I >still think that we can work on it and introduce some of your mechanisms I >propose then that we go back to that proposal, which has the kind of >grouping of elements that was agreed in the f2f and then to comment and >agree how to incorporate some of your proposals. >Specifically, I think that we could comment on how to accommodate your >indirection mechanisms in the original structure. > >As the rest of the people in the list has not seen the proposal I sent you , >below follows a very short descriptoin of the structure of this proposal and >more specific comments on the structure you circulated on the list. > >GENERAL STRUCTURE OF THE MESSAGE AND GROUPS OF ELEMENTS: >I will start with the first level structure of the message that you propose. >After reading it, I have to say that I would prefer the one that I proposed >to you.... >I will make a comparison with the one I proposed, which in fact followed the >general ideas that came up in the f2f meeting. >In my proposal, the root element had six children elements, >namelly: > > -RequestID, which, as Tim suggested should be converted in an attribute of >the root element. > > -UserData, containing information of the data to be signed, and that you >have renamed to InputDocuments. > > -KeySelector: element indicating to the server which key has to use. > You propose to make it optional.... I guess that this optionality would >match those environments where there is only one key by default. > > -ClaimedIdentity: optional element including the claimed identity of the >requestor. > > -Properties: optional element for requesting signed and/or unsigned >properties. > > -Options: optional element identifying different types of options: > -On the signature production > -On the result to be delivered to the requestor > -On the processing to be done by the server > -On the supporting information (profiles, signature policy, etc). > >In your proposal the root element has 8 children, and three of them include >the term "Options" in their name: > -RequestID. As I said before, I agree with Tim's proposal and make it an >attribute of the root element. > >-ServerGuidance. Here you include things like: claimedIdentity, >IntendedAudience, ApplicationProfile and Others...I do not agree nor with >this grouping neither with the name. > > In terms of the grouping I think that the claimedIdentity, when required >is something so important that deserves to be a direct child of the root >element by itself, as it is related with an essential fact of the signing >process: WHO WANTS TO SIGN THE DOCUMENT(S)!!!!. The qualitative nature of >this information is radically distinct of other information as the >ApplicationProfile, the IntendedAudience and the vague Others...In addition, >APplicationProfile and IntendedAudience, nicely fit within other categories >of elements already present in my proposal (IntendedAudience in >ResultDelivery, and ApplicationProfile within the Processing options!!!!) > > In terms of the name, ServerGuidance seems too vague for me: I mean, >almost anything in the request gives some kind of guidance to the server: >the key selector, the signature placement, etc... so I do not like the term >guidance as too vague. And this impression is reinforced by the completely >different purposes of the three contained elements. > > -SignatureContents: I have some comments on this structure: > > First: I do not like very much the name. It seems to me that it is >misleading. The element seems to contain indications on what processing the >server has to perform on each document by using selectors and transforms. >The term "SignatureContents" leads me to think of the different parts of the >Signature structure more than what actually is within the element. > > Second: As you say, this element would allow to apply different transforms >to the same document and then sign different outputs of these >transformations. I think that this is something that could be good to >incorporate to our request. > > Third: Obviously the WhichInputDocument would be better an attribute and I >personally prefer to use the "reference" attribute as I proposed you, >instead of indicating the order numbering of the documents.... > > Fourth: The Requirements document, in 3.4.2 explicitly mentions the >situation where the requester has applied some transformations to the >original data. Then it would be possible situations where the requester has >applied certain transformations and wants the server to apply other set of >transformations.... How does this structure accommodates such different >groups of transformations? > Would the transformations in your "SignatureContents" be the >transformations to be applied by the server AND the transformations within >InputDocuments the transformations applied by the requester? > IF so, I would propose to rename the elements to accomodate the purpose. >In my original proposal I distinguished between: > PerformedTransformations and RequestedTransformations, both of >ds:TransformsType. > > > > -SignatureOptions.You include here the information of the Key and the >request for properties (signed and/or unsigned). > > First: I think that > in the f2f meeting we had a sort of agreement in that the element >containing the information on the key that the server should use would be >KeySelector to stress the idea that in a service like ours this element >would select one of the different keys that the server > could use for signing the documents. I still thing that term "KeySelector" >is more aligned with the operational context of the service. > > Second: I would say that the information of the key that the server has to >use is something crucial to the service, whereas the addition of >properties, the canonicalization method, etc. is something of a second >level of importance: in the end, the key also identifies the signer!!!. So, >I think that, just as I proposed with the claimedIdentity the element >selecting the key should be a child of the root element. > -SignaturePlacement. You put this element as a direct child of the root >element. I disagree with that. For me it is far more relevant (from the >perspective of the service we are defining) WHO requests to sign something >and WITH WHICH KEY than whether the signature produced is enveloped, >enveloping or detached. I find much more natural to make this element a >child of a ResultOptions element, as in my proposal. > > -OutputOptions: I can not catch all the semantics there....I can only try >to guess. Reading the contents, one question comes to my mind: > Imagine that a requester sends five documents. He wants > two enveloped (let us say the 2ond and the 4rth). He wants > the third enveloping the signature. Then the requester > puts the element ReturnDocumentWithSignature, but how the > server can know that the requester wants the signature > enveloped in the third document and detached from the first > and the fifth? I have not seen any information in the whole > structure indicating this... > > -ProcessingOptions: I can not say much on this element because there is >not type there. In my proposal, it contained things like signature policy >identifier (an identifier of a signature policy, not the XAdES property!!) >and the serverprofile, as I understand that these two issues really >determine the kind of processing that the server will have to implement. > Related with this issue would also be the issue of stacking operations or >whatever we call it: the capability for requesting not one but several >operations in one request.... > Finally, just comment again that I think that an approach where the root >element would have only one child Options containing different children >each one corresponding to different types of options is much cleaner than >having three root children related to different options.... > > -InputDocuments. I also have a number of comments here: > First: the name. In the XMLDSIG the term used for the data that are >processed and signed is "data object" to emphasize the idea of that the >XMLDSIG can be used to sign whatever binary information we want. That is >why I used in my proposal hte name UserData, which seems to me that >reflects precisely this idea. > Second: In my proposal there was an optional element that could have more >than one instance, called ReferenceRequestDetails. The content of each >instance would contain a ds:Reference element. This definition allows to >accomodate the situation where the requester performs the transformations >and hash computations by herself and only wants that the server builds up >the ds:Signature element and computes the digital signature. You have >substituted that definition by a group of three elements: Transforms, >digestMethod and digestValue. Well, with only these three elements, the >server CAN FACE SITUATIONS WHERE IT CAN NOT BUILD UP THE ds:Signature. THE >ds:Reference elements CAN HAVE UP TO THREE ADDITIONAL ATTRIBUTES, ONE OF >THEM OF CAPITAL IMPORTANCE IN DETACHED SIGNATURES: Uri!!!! > I think that if we have to accommodate situations where the requester wil >have the capability of transforming data and computing hash, we should >assume that she will be able to build up the corresponding ds:Reference >elements (as she is the one who knows the Uri where to locate the data, and >the type of the original data and even if she wants to give an Id to the >data!!!)... IN SUMMARY, I THINK THAT THIS ELEMENT SHOULD HAVE THE CONTENTS >OF ds:Reference... > > >Regards >Juan Carlos > > > > >Yahoo! Messenger >Nueva versión: Super Webcam, voz, caritas animadas, y más ˇGratis!
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]