[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Compound operation Verify & Sign
-----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 .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]