FW: FROM JUAN CARLOS: FIRST COMMENTS TO TREVOR SCHEMA

["Nick Pope" <pope@secstan.com>]

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!