Fwd: RE: FROM JUAN CARLOS: FIRST COMMENTS TO TREVOR SCHEMA

[Trevor Perrin <trevp@trevp.net>]

 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!