RE: [dss] RE: ProcessingOptions example and discussion

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

Colleagues - Two comments; one minor and one a bit more significant.  First
the minor one ...

A more efficient way of encoding the various options is as an empty element.
So, they would appear like this ...

<IncludeTimeStampXAdES-A/>
<ReturnDetachedTimeStampToken/> 

Instead of like this ...

<IncludeTimeStampXAdES-A>true</IncludeTimeStampXAdES-A>
<ReturnDetachedTimeStampToken>true</ReturnDetachedTimeStampToken>

The second thing is that these processing options are an expression of
security policy.  There is a distinct trend towards moving security (and
other types of) policy into an infrastructure layer.  Statements in the
policy language will be opaque to clients.  They may pass them to a service
like the one we are defining, they may provide a reference to them, or they
may leave all that entirely up to the service to figure out.

There are a number of candidate languages.  See WS-Policy and WSPL (from the
makers of XACML).

Therefore, we need an open container for passing instances of any security
policy language or a reference to an instance.

It will (of course) be possible to accommodate Ed's expressions in this
container.

All the best.  Tim.

-----Original Message-----
From: Edward Shallow [mailto:ed.shallow@rogers.com]
Sent: Wednesday, September 03, 2003 4:16 PM
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