OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dss] FW: FROM JUAN CARLOS: FIRST COMMENTS TO TREVOR SCHEMA



Hi Juan Carlos, Nick -

inline, sorry for the length.


At 10:25 AM 8/29/2003 +0100, Nick Pope wrote:

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

Yes, I changed a lot.  I apologize for doing that after you left, behind 
your back so to speak.  I should have posted both our versions, since we 
didn't have time to work to a consensus.

Anyways, here's the last proposal from you, so people can review it, and 
here's the message I sent you explaining the changes.  Hopefully we can 
discuss which approaches are best and get consensus.

http://trevp.net/dss/DSSTCESQ-SIGNREQUEST_v_0_11.xsd
http://trevp.net/dss/DSSTCESQ-SIGNRESPONSE_v_0_1.xsd
http://trevp.net/dss/email.txt


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

I propose we consider them as alternate proposals, and try to decide which 
elements of each are best.

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

Or where the server can choose the key, based on e.g. ClaimedIdentity.


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

Okay.  Is it just convention to make short strings attributes?


>-ServerGuidance. Here you include things like: claimedIdentity,
>  IntendedAudience, ApplicationProfile and Others...I do not agree
>  nor with this grouping neither with the name.

It's not a great name, and it is sort of a grab bag - these are things that 
don't correspond 1-to-1 to any particular element of the signature.  The 
server can take these things into advisement in determining what key to 
use, what signed attributes to add, etc..


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

Are we looking at the same thing?  In the last thing you sent me, on 8/4, 
aren't IntendedAudience and ServerProfileIdentifier both within 
ProcessingOptions?


>  In terms of the name, ServerGuidance seems too vague for me:

It's vague, but I don't find "ProcessingOptions" much better.

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

"ServerGuidance" is things that don't correspond directly to an aspect of 
the signature, where "SignatureOptions" was things that did (use this key, 
add this signed attribute).  Made sense to me, but I guess commonality is 
in the eye of the beholder here.



>  -SignatureContents: I have some comments on this structure:
>
>  First: I do not like very much the name.

Agreed.

>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

What's the criteria for attributes vs. elements?

>  and I personally prefer to use the "reference" attribute as I proposed
>  you, instead of indicating the order numbering of the documents....

I don't like the name "reference", since we also have ds:Reference and URL 
references floating around.  And I think an index value is simpler than 
having to find a string match.


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

That was the intent.

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

On the last 2 points: when incorporating DSIG elements, I left their names 
unchanged, which I thought would make things easier to read.  But you may 
be right, it may be preferable to give these more specific names.


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

Yes, that needs some text to explain.

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

It would be in SignaturePlacement.  Which isn't defined yet because I don't 
know how to do this.  I don't understand how your approach of using a 
ds:Transforms would work.


>  -ProcessingOptions: I can not say much on this element because
>  there is not type there.

It's a placeholder, Ed's proposing some uses for it.

>In my proposal, it contained things like
>  signature policy identifier (an identifier of a signature policy,
>  not the XAdES property!!)

I'm confused.  What is a signature policy as distinct from a signature 
policy identifier?

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

Why "User"?  And "Data" is vague, everything's data.  I think "Documents" 
is the best term we have for the things the signature is calculated over.

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

DocumentBaseType has URI and Type attributes, like a dsig:Reference.


Trevor 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]