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
