RE: [dss] RE: ProcessingOptions example and discussion

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

Tim,

See below:

> -----Original Message-----
> From: Tim Moses [mailto:tim.moses@entrust.com]
> Sent: 02 September 2003 15:39
> To: 'Nick Pope'; OASIS DSS TC
> Cc: Ed Shallow
> Subject: RE: [dss] RE: ProcessingOptions example and discussion
>
>
> Colleagues - Forgive me if I have missed a step in this
> discussion. But, for
> my part, I would like to see an enumeration of all anticipated compound
> operations, an enumeration of the technical options for
> supporting compound
> operations and a discussion of the pros and cons of each approach.
>
> Without giving it too much thought, it seems to me that there are at least
> four possible approaches ...
>
> 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.

I think that this places the complexity on the use of operations in
combination with the user, and depends on the user to apply the appropriate
policy

For example, if a time-stamp is to be applied after signing then the user
has to handle the two operations and rules for recovery in case the second
one fails.  Doing it in the server avoids the user having to worry about all
the complexities.

Also, where the service being provided is a combination of, say verification
and countersigning based on the success of verify, such as in some forms on
notarisation, it would not be feasible for the oeprations to be handled
separately by the user.

>
> 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.
>
Again, I don't think that the situation is as simple as that.   For example,
depending on the type of time-stamping required different parts of the
signature are to be time-stamped.


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

Provided that this is extensible I have no problem with this.  I suggest
however, that we have a generic request/response structure which is
applicable to the different type of simple / compound operations.

>
> 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.
>
I slightly prefer 3 as in many cases it is unclear to me which basic
operation is the one to start from.  For example, is sign and verify is an
extension to the sign or verify?  Is sign and time-stamp an extension to
sign or time-stamp ......


> I must say, I like options 1 and 2: they seem to lead to simpler message
> syntax.

My preference is for 3 then 4.  I do not think that 1 meets the needs of all
the use cases (e.g. notarisation) and I think 2 could become very with a
variation of parameters being passed from one to the next part of the
compound operation depending on the function.
>
> Is someone prepared to lay out the pros and cons of the various
> approaches?
> All the best.  Tim.

This is one view.

>
>
>
> -----Original Message-----
> From: Nick Pope [mailto:pope@secstan.com]
> Sent: Thursday, August 28, 2003 12:36 PM
> To: OASIS DSS TC
> Cc: Ed Shallow
> Subject: [dss] RE: ProcessingOptions example and discussion
>
>
> Ed,
>
> Now that you are on the DSS list can I kick off discussions on
> this example
> with two thoughts (I am working extra hard today :-)
>
> a) Do we envisage the DSS to define other complex operations such
> as verify
> and countersign, extend signature with validation data, archive
> time-stamp.
> Would these be defined in the core or as part of the profiles?
>
> If these are defined in profiles, how do we avoid similar operations being
> redefined. I particularly see there is significant overlap
> between compound
> operations for EPM and XAdES profiles.
>
> b) If we have compound operations that involved sign & verify.
> Which of the
> current request - response protocols does this come under?  Or do
> we want a
> single message structure for all the different operations and use
> processing
> options to also control the basic operations?
>
> Nick
>
>
>
> PS.  Ed, Can you confirm that you get a second copy of this
> message through
> the DSS list.
>
> > -----Original Message-----
> > From: Edward Shallow [mailto:ed.shallow@rogers.com]
> > Sent: 17 August 2003 23:18
> > To: 'Trevor Perrin'; Cruellas@ac.upc.es; 'Nick Pope'
> > Cc: Gray Steve
> > Subject: ProcessingOptions example and discussion
> >
> >
> > Nick, Juan-Carlos, and Trevor,    (... please post, tks)
> >
> >   Based partly on Trevor's feedback on the timestamp types post,
> > 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>
> >
> >
> >
> >
> >
>
>
>
> To unsubscribe from this mailing list (and be removed from the
> roster of the
> OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wor
kgroup.php
.

To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
.