Fwd: RE: Way ahead - Extensibility Sentence

[Trevor Perrin <trevp@trevp.net>]

 From Ed -


>Nick, Trevor, and Juan-Carlos (please Post to List)
>
>      Here is some input and a discussion framework on "ProcessingOptions"
>aka CompoundOperations (bad), aka StackedOperations (bad), aka
>ExtendedProcessing (O.K.) concept ... broken down by topic category. You can
>break this up and post the pieces individually if you prefer, in order to
>focus the feedback.
>
>One of the more important relationships that exist and influences the
>"ProcessingOptions" notion is the one which exists with TimeStamping. I will
>ask for clarification on a few scope issues before proceeding into the
>ProcessingOptions discussion.
>
>Scope Questions
>***************
>
>1) If one agrees that there could exist more than one type of a timestamp,
>which types of timestamps is DSS intending to support ? As a starting point,
>and in the absence of any suggested references todate, may I be so bold as
>to use the ETSI 101 903 definitions as a basis for the question ? Please
>refer to the ETSI document for detailed descriptions, sections included.
>
>a) AllDataObjectsTimeStamp - a "content" TimeStamp produced before signature
>creation over the sequence of all ds:References (this excludes the
>SignedProperties), it itself is an optional SignedPoperty (see 7.2.9, and
>another TimeStamp variation called IndividualDataObjectsTimeStamp covered in
>7.2.10)
>
>b) SignatureTimeStamp - with this timestamp the input for the timestamp hash
>computation is the ds:SignatureValue XML element, produced after signature
>creation
>
>c) XAdES-T TimeStamp - timestamp computed over the entire XAdES (or DSS
>equivalent in our case) structure itself
>
>d) There are 2 alternate forms of XAdES-X which can be used and are as
>follows:
>
>d1)SigAndRefsTimeStamp - as per SigAndRefsTimeStamp element definition (see
>7.5.1)
>
>d2) RefsOnlyTimeStamp - for this type, the hash sent to the TSA will be
>computed then over the concatenation of CompleteCertificateRefs and
>CompleteRevocationRefs elements (see 7.5.2). Offers easier manageability and
>performance
>
>e) Archive TimeStamp - timestamp computed over entire XAdES-X-L
>
>Discussion and Concept Recommendation
>*************************************
>
>The "Update" and/or "Refresh" protocol discussions are clearly in the same
>domain as much of the above. In fact one of the main thrusts of 101-733/903
>was to ensure the validity of signatures over long periods of time. Given
>that the "Update" operation is intended to re-produce this desired validity,
>it behooves us to take a closer look at the afore-mentioned standard.
>
>Now to bring the discussion back full circle to how all this relates to
>"ProcessingOptions", I contend it would be a mistake to have users specify
>what TimeStamp type they want in their requests as part of Signed/UnSigned
>Properties structure. Rationale being, they will invariably tend to get it
>wrong (i.e. ask for attributes of a certain type thinking that this will
>result in a timestamp of a certain type. This will just cause excessive
>server-side validation. The make-up of the QualifyingProperties element
>(i.e. Signed and UnSigned Properties) should be the "result" of DSS
>processing and not input to it. After all, these elements were loosely
>borrowed from the element make-up and layout of resultant signature
>standards which we are using within our "request" structure. A quick review
>of 101-733/903 shows the specific structure layouts and dependencies for
>each TimeStamp type. Their makeup is standardized and involves multiple
>output parts. Please refer to document.
>
>A better approach IMHO is to have the user specify what kind of a TimeStamp
>or Update they want as a simple boolen flag or directive in the
>ProcessingOptions enumeration. The DSS server would then simply honour the
>request responding with the "appropriate" return structure reflecting the
>specific nature of the TimeStamp requested and not what the user thinks the
>structure is. This might even do away with the need for a separate "Update"
>or "Refresh" operation. Some example sub-types of ProcessingOptions might
>run as follows: "IncludeContentTimeStamp" (a synonym of the ETSI's
>AllDataObjectsTimeStamp), or "ProduceValidationDataRefsTimeStamp".
>
>As a thought, we might simply decide to refer to/import the ETSI 101 903
>namespace qualifier "htttp://uri.etsi.org/01903/v1.1.1#" for the above names
>and use ETSI's element names as is. Clearly we could look at the subset
>required by the European Directive to make our lives simpler.
>
>On another "ProcessingOptions" related subject, the EPM also uses
>"ProcessingOptions" for specifying what Info to Return. DSS already has this
>covered with "OutputOptionsType", that is fine. However, I see an overlap
>emerging between "ProcessingOptions" (more general) and "OutputOptions"
>(more specific).
>
>For example when a TimeStamp is returned as a separate artifact, which is
>the case for certain types, is the user not just simply requesting output ?
>Possibly. We saw this more clearly and succinctly expressed as firstly "What
>do you want done ?" and secondly "What output consequences result from this
>request ?". When you look at it this way, all directives to the DSS service
>to support the primitive verb go in "ProcessingOptions", and then the DSS
>Service will return appropriate and consistent output structures, a much
>simpler approach from the user's viewpoint. I am not suggesting doing away
>with "OutputOptionsType" altogether, but rather making sure that if optional
>output is a direct consequence of a supporting "ProcessingOption", then it
>should be requested via "ProcessingOptions". The same rationale applies to
>Signed and Unsigned Properties. That is, "Don't have users specify output
>structure" and "Don't have users specify what they want performed in too
>many different places". We have at least 3 separate places where users must
>specify "What they want done".
>
>At the risk of lecturing, I invite everyone to read up on ETSI 101 903 and
>its overall defintion of TimeStamp types and handling approach as well as
>its Signed and Unsigned Property structures.
>
>If we get some common ground on the above, I'll flesh out the specific
>recommendations with pertinent structure examples.
>
>Awaiting feedback.
>
>Ed
>
>
>
>
>
>
>-----Original Message-----
>From: Nick Pope [mailto:pope@secstan.com]
>Sent: August 15, 2003 4:13 AM
>To: Edward Shallow; 'Trevor Perrin'
>Cc: 'Juan Carlos Cruellas'
>
>OK - Assuming that you are happing with that you are happy with the revised
>requirements document, it over yopu to you on Compound operations.
>
>Nick
>
> > -----Original Message-----
> > From: Edward Shallow [mailto:ed.shallow@rogers.com]
> > Sent: 14 August 2003 20:28
> > To: 'Trevor Perrin'; 'Nick Pope'
> > Cc: 'Juan Carlos Cruellas'
> > Subject: RE: Way ahead - Extensibility Sentence
> >
> >
> > On the topic of the requirements document sentence, the text below is
> > just fine, crisp and clear.
> >
> > On the 2nd note below, Trevor referred to 3 schema versions sent by
> > Juan-Carlos the last of which had a ProcessingOptionsType. This is the
> > version I had not as yet seen. Again, I repeat, I will add elements
> > and maybe additional types to this structure referred to in last nights
>eMail.
> >
> > Perhaps it would be better if the team just sends me the lastest, and
> > I'll add the "suggested" additional elements to it along with the 200
> > word explanation I mentioned on the conf call.
> >
> > As for "... I'm not thrilled with adding an unspecified element when
> > we have no clear picture of what goes inside it ..."
> >
> > My impression was that it has been discussed to death (verbally and on
> > the list), and we are moving forward with it. Given that it is at
> > least clear in my mind, I am volunteering to help flesh this out as
> > described above.
> >
> > Agreed ?
> >
> > Awaiting the latest update
> >
> > Cheers,
> > Ed
> >
> >
> > -----Original Message-----
> > From: Trevor Perrin [mailto:trevp@trevp.net]
> > Sent: August 14, 2003 1:41 PM
> > To: Nick Pope; Ed Shallow
> > Cc: Juan Carlos Cruellas
> >
> > At 04:06 PM 8/14/2003 +0100, Nick Pope wrote:
> > >Content-Transfer-Encoding: 7bit
> > >
> > >Ed, Trevor,
> > >
> > >I think exactly how stacked / compound operations work is not
> > >something we can answer immediately.  I fealt that there was the view
> > >from the f2f that something in this area was required but how it
> > >worked in the protocol requires further discussion.
> > >
> > >I suggest that:
> > >
> > >A) We add some general text to the requirements document on the need
> > >to support "compound" operations (I personally find the word "stacked"
> > >operations misleading).
> > >
> > >I propose that the existing section 3.9 text is replaced with the
> > following:
> > >
> > >"3.9 Compound Operations
> > >
> > >The protocol will support Compound operations where a single request
> > >/ response to a DSS server results in a combination of the sign /
> > >verify / time-stamp processes.
> > >
> > >Example of such compound operation is ..... (as in existing 3.9).
> >
> > I'll make that change, if Ed agrees.
> >
> >
> >
> > >3.10 Extensibility
> > >
> > >The protocol will be flexible and extensible so that particular
> > >response elements or signing attributes may be selected, either
> > explicitly
> > or via an
> > >application profile.   This will be able to support the flexibility of
> > >alternative compound operations."
> >
> > 3.11.1 discusses protocol extensibility.  Do we need to add a new
> > section just for this?
> >
> >
> >
> > >----
> > >
> > >B) That for the moment we have a place holder in the core schema called:
> > >"ProcessingOptions" but leave the exact usage of this field
> > open.  We also
> > >progress work on the schema required for simple sign, verify and
> > time-stamp
> > >operations.
> >
> > I'll add a <ProcessingOptions> placeholder, if Ed's agrees.  I hope it
> > becomes apparent soon what we're going to use it for, though.  I'm not
> > thrilled with adding an unspecified element when we have no clear
> > picture of what goes inside it.
> >
> >
> > >If this is acceptable to both of you then I will send this out to the
> > >general list and ask that, Trevor, you produce a revised requirements
> > >document, and if possible Core Schema before you depart this week end.
> >
> > Like you mention, it might be a good idea to post this to the list, so
> > people know that some decisions were made off-list.
> >
> > Trevor
> >
> >
> >
> >
> >