RE: [dss] RE: ProcessingOptions example and discussion

[Tim Moses <tim.moses@entrust.com>]

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.

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.

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

Is someone prepared to lay out the pros and cons of the various approaches?
All the best.  Tim.



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