RE: [dss] RE: ProcessingOptions example and discussion

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

Ed,

Wow do you think that the use of process options fits in with the options
suggested by Tim:

> 1. All operations are atomic.  Compound operations are built by clients
> making multiple calls to different services.  Some technique for
> linking the
> output of one operation to the input of the next would have to be defined.
>
> 2. Request messages can be concatenated, with an option to
> indicate that the
> input token in one request is to be the output token from the previous
> request.
>
> 3. All operations (including compound ones) are identified by their own
> request type identifier.  We would define a few useful ones.  Others could
> define their own in profiles.  Each compound-operation message should be
> derived from the general message syntax defined in the core document.
>
> 4. Compound operations are variants of our existing sign, timestamp and
> verify request types.  All variations in syntax would have to be
> captured in
> the basic syntax.
>

And the suggestion put forward subsequently on the possible combinations:
> >Here they are ...
> >
> >VS, VT, ST, TS, VST, VTS.

Reduced by trevor to:

> So if we can use S* for (S, T, ST, or TS), then the only "compound
> operation" is VS* - first verify, then update/ refresh/ augment/ whatever
> the signature.
>

If we have the basic operations Sign, Vertifiy, Timestamp & VerifySign with
ProcessOptions identifying further options for processing within these basic
operations
(e.g. addition of time-stamping of various types) as well as controlling the
EPM extensions such as encryption, proof of delivery receipt), would this
work for you?

Nick








> -----Original Message-----
> From: Edward Shallow [mailto:ed.shallow@rogers.com]
> Sent: 03 September 2003 21:16
> To: 'Trevor Perrin'; 'Tim Moses'; 'Nick Pope'; 'OASIS DSS TC'
> Subject: RE: [dss] RE: ProcessingOptions example and discussion
>
>
> On the subject of ProcessingOptions, the recent discussions seem to be
> narrowing (and complicating) the original envisioned scope of the
> ProcessingOptions construct. The 1st memo below, which provides
> more insight
> into its intended use, never made it to the list. It was sent to Trevor,
> Nick, and Juan-carlos on the 15th of August. Now that I have an
> account, I'm
> cc'ing the list for your review. The 2nd has been attached for
> convenience.
>
> The 1st memo started off with a series of scope questions which
> were felt to
> have a direct bearing on the scope of the "ProcessingOptions" and its
> evolution. Only Trevor has responded todate. I do not think we have
> consensus on the responses to these questions as yet. The memo
> then goes on
> to describe a concept and recommended starting point for the
> "ProcessingOptions" construct. I was tasked at the face-to-face with doing
> that. May I suggest that feedback and rebuttal use this tabled
> suggestion as
> a starting point.
>
> I contend that the user should not be concerned with whether an
> operation is
> compound or not, but rather simply "What do you want done ?" and secondly
> "What processing and output consequences result from that request ?".
>
> The "ProcessingOptions" construct plays a pivotal role in
> allowing the user
> to specify in a straightforward way "What they want done". I also
> agree with
> Trevor that this expression of desire should only be required if it is an
> exception or override to the default profile handling. I disagree that
> default profile handling eliminates the need for the request construct
> entirely, that is why we have minoccurs="0".  In fact, as my suggested
> schema shows, the collection of "ProcessingOptions" goes a long way to
> actually expressing not only the default profile handling, but also the
> profile-specifc extended handling and represents a tangible
> manfestation of
> core and extended profile handling. See XML below.
>
> I disagree violently to the suggestion that we don't need a framework for
> "ProcessingOptions" handling. If a particular ProcessingOption entails the
> execution of more than one operation, so be it. If it acts solely as a
> directive to the server, so be it. It is still simply a
> "ProcessingOption",
> and we definitely need a framework for handling them.
>
> Awaiting feedback and responses on the "Scope Questions" and the
> "ProcessingOptions" schema below.
>
> Ed
>
>
>
>
> Here is the 1st memo ...
> ********************
>
>      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.
>
>
>
> This 2nd memo followed shortly thereafter ...
> *****************************************
>
>   Based partly on Trevor's feedback to the above, as well as
> the need to start getting down to examples, here is a mock-up of
> how to take
> advantage of the ProcessingOptions request structure. I will
> follow this up
> (soon I hope) with some response structure samples that get impacted.
> Additonally I have shown how it might be extended for the EPM profile.
> Please treat as a sample for now, and not an official EPM profile
> submission.
>
>   This approach allows for defaulting and easy profile extension.
> As stated
> in my previous post which discussed timestamp requesting, a clearer
> separation and prority is given to "What you want done ?" versus "What you
> want returned and where to put it". Requesting a timestamp belongs in the
> former. Deciding what it looks like and where it goes is the
> responsibility
> of the DSS implementation. This will avoid incorrect specification of
> timestamp details and simplifies the request structure. Other uses beyond
> compound operations are also shown below. This is consistent with the more
> general definition I have submitted. There is a loose categorization shown
> below which could be formalized into the schema if people prefer.
> However if
> it confuses rather than clarifies, then I see no need. Options
> could also be
> separated by primitive if desired (e.g. Sign options, Verify options, etc
> ...). Again, this is a subjective "clarity and succinctness" question.
>
> Cheers,
> Ed
>
> P.S. It was agreed that primitives outside the scope of DSS will
> never find
> there way into any DSS profile (e.g. Encrypt, Decrypt, StartLifecycle, etc
> ..). However, if an implementation wishes to extend an existing primitive
> (e.g. Sign, Verify), it is free to do so within the implementation-specifc
> profile extensions. This is evident in the examples below.
>
>
>
> <xs:element name="ProcessingOptions" type="ProcessingOptionsType"
> minOccurs="1"/>
>
> <!-- This is the base type upon which core is built -->
>
> <xs:complexType name="ProcessingOptionsType">
>   <xs:sequence>
>
> 	<xs:element name="UtilizeDefaults" type="xs:boolean" minOccurs="0"/>
> <!-- explicitly stated, mutually exclusive with all other options -->
>
> 	<xs:element name="IncludeContentTimeStamp" type="xs:boolean"
> minOccurs="0"/>    <!-- PKCS7/CMS and XML -->
> 	<xs:element name="IncludeSignatureTimeStamp" type="xs:boolean"
> minOccurs="0"/>  <!-- XML only, essentially an XAdES-T -->
>           ...  <!-- could be more, TBD -->
>   <xs:sequence
> </xs:complexType>
>
>
> <!-- This is a draft sample of the EPM profile extension which
> inherits then
> extends the base -->
>
> <xs:complexType name="EPMProcessingOptionsType">
>   <xs:complexContent>
>     <xs:extension base=ProcessingOptionsType>
>       <xs:sequence>
>
> 	  <xs:element name="UtilizeProfileDefaults" type="xs:boolean"
> minOccurs="0"/>
>
> 	  <!-- TimeStamping Options -->
>         <xs:element name="IncludeTimeStampXAdES-X" type="xs:boolean"
> minOccurs="0"/>
>         <xs:element name="IncludeTimeStampXAdES-X-L" type="xs:boolean"
> minOccurs="0"/>
>         <xs:element name="IncludeTimeStampXAdES-A" type="xs:boolean"
> minOccurs="0"/>
>         <xs:element name="ReturnDetachedTimeStampToken" type="xs:boolean"
> minOccurs="0"/>  <!-- Applies to PKCS7/CMS only, could also be in core -->
>             ...
> 	  <!-- Additional Crypto Operations Options -->
>         <xs:element name="VerifyCertificate" type="xs:boolean"
> minOccurs="0"/>  <!-- Normally True, but can be used to suppress CRL/OCSP
> check -->
>         <xs:element name="EncryptThenSign" type="xs:boolean"
> minOccurs="0"/>
> <!-- For confidentiality, encrypt content to be signed -->
>         <xs:element name="DecryptIncomingEnvelope" type="xs:boolean"
> minOccurs="0"/>  <!-- Used on Verify only -->
>             ...
> 	  <!-- Receipting Options -->
>         <xs:element name="IssueProofOfPossessionReceipt" type="xs:boolean"
> minOccurs="0"/>
>         <xs:element name="IssueProofOfSubmissionReceipt" type="xs:boolean"
> minOccurs="0"/>
>         <xs:element name="IssueProofOfDeliveryReceipt" type="xs:boolean"
> minOccurs="0"/>
>         <xs:element name="IssueCertificateOfVerificationReceipt"
> type="xs:boolean" minOccurs="0"/>
>         <xs:element name="IssueCombinedReceipt" type="xs:boolean"
> minOccurs="0"/>
>             ...
> 	  <!-- Lifecycle Control Options -->
>         <xs:element name="StartLifecycle" type="xs:boolean"
> minOccurs="0"/>
>         <xs:element name="EndLifecycle" type="xs:boolean" minOccurs="0"/>
>             ...
> 	  <!-- Return Additional Info Options -->
>         <xs:element name="ReturnExtendedStatusInfo" type="xs:boolean"
> minOccurs="0"/>  <!-- Returns extended status info and info from TSA,
> OCSP-->
>         <xs:element name="ReturnValidationDataAsText" type="xs:boolean"
> minOccurs="0"/>  <!-- Returns human readable OCSP response -->
>         <xs:element name="ReturnSignatureInfo" type="xs:boolean"
> minOccurs="0"/>  <!-- Returns selected signature attributes
> separately  -->
>         <xs:element name="ReturnCertificateInfo" type="xs:boolean"
> minOccurs="0"/>  <!-- Returns selected cert attributes separately-->
>             ...
>       <xs:sequence>
>     <xs:extension>
>   <xs:complexContent>
> </xs:complexType>
>
>
> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: September 3, 2003 11:16 AM
> To: Tim Moses; 'Nick Pope'; OASIS DSS TC
> Cc: Ed Shallow
>
> At 10:36 AM 9/3/2003 -0400, Tim Moses wrote:
>
> >Colleagues - OK.  Let's get a list of compound operations before we
> >decide how to deal with them.  If there are three primitives (V,S & T)
> >and if it is not valid to repeat an operation and if it makes no sense
> >to do V anywhere but as the first operation, then there are four
> >possible dual-operations and two possible triple-operations (see
> >below).  I don't think it makes sense for us to say which of these are
> >invalid: someone may one day want to do any one of them.  We should
> >simply provide the framework in which one could do any one of them.  All
> the best.  Tim.
> >
> >Here they are ...
> >
> >VS, VT, ST, TS, VST, VTS.
>
> I like this approach.
>
> I would contend that ST and TS are just instances of the Signing
> Protocol -
> they're producing a signature that contains some sort of
> TimeStamp.  But the
> client may not need to explicitly request the signature, or he may request
> the signature just by passing an "ApplyTimeStamp" boolean.  I
> would not call
> such a simple technique a "compound operation".
>
> I also contend that T should be a profile of the signing protocol, as I've
> argued before.
>
> So if we can use S* for (S, T, ST, or TS), then the only "compound
> operation" is VS* - first verify, then update/ refresh/ augment/ whatever
> the signature.
>
> So I'd argue we don't need a general framework for compound operations, we
> just need to support this *particular* compound operation.  This
> simplifies
> the problem.
>
> Do people agree?
>
>
> Trevor
>
>
>
>
>