Re: [dss] Fwd: RE: Way ahead - Extensibility Sentence

[Trevor Perrin <trevp@trevp.net>]

At 02:42 PM 8/15/2003 -0700, Trevor Perrin wrote:


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

It's clear what you mean - but I think this question would be better 
phrased as "which type of *timestamped signatures* is DSS intending to 
support?".  This emphasizes the difference between using DSS to produce a 
time-stamp, and using it to produce a signature with a time-stamp 
attribute.  You're talking about the latter.

To be even more pedantic, we can separate "intending to support" into 2 
questions:
  1) can the protocol be used to produce a signature with a certain type of 
time-stamp?
  2) can the protocol be used to *explicitly request* a signature with a 
certain type of time-stamp?

For the 1st, the answer should be yes to everything.  If a time-stamp is 
just an attribute to a signature format we support, there should be no 
trouble with returning a signature containing such a time-stamp.

So your question is about the second -  what type of support do we need in 
the SignRequest message for the client to explicitly control timestamps on 
signatures?

It's not clear to me that we need *any* explicit support for this.  Perhaps 
an ApplicationProfile would say "always apply a SignatureTimeStamp", or 
"always apply an AllDataObjectsTimeStamp", or whatever.  Then the client 
gets no control at all.

Or maybe the ApplicationProfile would say "if the client requests a 
time-stamp, then apply a SignatureTimeStamp".  Then the client would just 
say "timestamp/don't timestamp", and the server would know which type to apply.

My point is: this isn't a question of "do we support these types of 
time-stamps or not", it's a question of "how much control do we give the 
client".


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

That's basically the same as this document, right?
http://www.w3.org/TR/XAdES/



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

Agreed.



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

Yup.  Users will screw up anything you ask them to do.

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

I agree.  I think of the "SignatureOptions" element, where the client 
explicitly says "use this key", or "use these signed attributes", as sort 
of an override mechanism where the client tries to take control into his 
own hands.  I hope we only need to use this in special cases.


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

In my opinion we should make it implicit in the Application Profile - you 
get whatever timestamp comes with the Profile.

If you really need to override, you could use the 
SignatureOptions/UnsignedProperties to try to give the server more specific 
directions.

This is another variant of the implicit/explicit debate.  There's all sorts 
of things a server could stuff in a signature, or different ways he could 
process it.  Just looking at XAdES, the server could stick in 
CounterSignature, SignerRole, SignatureProductionPlace, 
CommitmentTypeIndication, DataObjectFormat, all the flavors of time-stamps 
you mention...  He could produce an XAdES-T or -C or -X or -X-L signature...

We need to ask ourselves if the client really needs to specify these things 
on a request-by-request basis.  If a client will always be issuing a 
request with the same parameter value to a server, I think that's a good 
indication that that parameter should be part of the ApplicationProfile or 
part of the server's Implicit Parameters, and shouldn't be an explicit part 
of the protocol.

I think time-stamps on signatures fall into that category.  But I could be 
wrong.

Trevor