RE: [dss] Compound operation Verify & Sign

[Trevor Perrin <trevp@trevp.net>]

At 03:36 PM 11/4/2003 -0500, Edward Shallow wrote:

>Trevor wrote ... "And these "updated" signatures aren't necessarily
>time-stamps, right? " ...
>
>This is debatable, but ETSI and most other stakeholders believe they are.
>See XAdES-C, XAdES-X, XAdES-X-L, and XAdES-A. All are timestamps most of
>which can update the signature. Perhaps this is where the disconnect is ?
>
>We are obliged to support these constructs in Europe, and yes they involve
>additional Validation Data such as cert chain refs and revocation info.
>However this additional info is always timestamped.

XAdES-C augments XAdES-T (which is time-stamped), but doesn't add a timestamp.

Similarly, XAdES-X-L augments XAdES-X but doesn't add a timestamp.

So couldn't there be a DSS server that "upgraded" a signature to these 
types, by just adding certificate and revocation references/data, but not a 
timestamp?



>In fact, in the case of an Archive TimeStamp, it is not essential that you
>re-Verify prior to "Freshening" the TimeStamp. If you do it on a regular
>basis in advance of cryptographic exposures.
>
>To your other point, these "Freshens" as we colloquially refer to them, need
>NOT be on the back of a Verify operation. Would that mean they are handled
>as part of our core Sign operation ?

I don't know.  That's why this is a hard problem - it's not clear whether 
"freshening" a signature should be an option on Verify, an option on Sign, 
or its own operation!


>  Do we not need a dedicated Option to
>reflect this directed request for a TimeStamp ?

I don't understand the question, sorry.



>Sorry to send us down this rat hole, but we really haven't adequately
>discussed these issues, not the impact on the schema.

We've tried, it's just hard.  We've considered:
a) option on Sign
b) option on Verify
c) VerifyAndSign operation

yet nothing's really stuck.  So I dunno, I'm open to anything you suggest.

Trevor