RE: [dss] Compound operation Verify & Sign

["Edward Shallow" <ed.shallow@rogers.com>]

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: November 4, 2003 4:04 PM
To: Edward Shallow
Cc: dss@lists.oasis-open.org
Subject: RE: [dss] Compound operation Verify & Sign

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.

<ed>Yes you are right, I stand corrected. Good catch.</ed>

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?

<ed>
Yes, I believe we should accomplish this on the back of:

1) the Verify operation with a suitable "Options" directive like
<IncludeCertificateAndRevocationRefs/> or <IncludeXAdES-C/>. This would be
appropriate when the Verify request follows closely in time the initial
signature creation event (via DSS or not).

AND ...

2) the Sign operation when there has been a time lag since the signature was
originally verified. Again it should be accomplished via an "Options"
directive, and the signature would have to be included in the incoming
request structure.

Thus it would be BOTH your a) and b) below. 

</ed>





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

<ed>

I was simply asking, that if we request the Upgrade or Signature on the back
of the Sign, we should use the above discussed "Options" directives (i.e.
<IncludeCertificateAndRevocationRefs/> or <IncludeXAdES-X/> )   



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

<ed>
Great. BTW, you are doing an absolutely stupendous job !!! 
I certainly appreciate it.
</ed>

<ed>
We still have to tackle the core versus extended profile implications on the
above
</ed>

Trevor


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
.