[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Compound operation Verify & Sign
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. This is more than best-practice, it is mandated. 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 ? Do we not need a dedicated Option to reflect this directed request for a TimeStamp ? Sorry to send us down this rat hole, but we really haven't adequately discussed these issues, not the impact on the schema. I'm sure we'll get through it, do not despair. Ed -----Original Message----- From: Trevor Perrin [mailto:trevp@trevp.net] Sent: November 4, 2003 3:03 PM To: Edward Shallow; 'Nick Pope' Cc: dss@lists.oasis-open.org Subject: RE: [dss] Compound operation Verify & Sign At 02:41 PM 11/4/2003 -0500, Edward Shallow wrote: >Content-Transfer-Encoding: 7bit > >Trevor, > > When I mentioned embedded versus detached, I meant embedded as an >unauthenticated attribute in the ASN.1 signature structure (for >PKCS7/CMS) or embedded (the norm) as an unsigned property in the object >element (for XMLDSIG). > > This distinction affects the response structure, especially in the >PKCS7/CMS case. Many implementations today do not support ASN1 >embedding of timestamps. Perhaps they should, but I don't think it is >within DSS' mandate to dictate they must (e.g. Authentidate). > > Bottom line: 2 separate response elements on a Sign operation for >example. > > This simple illustration is just the tip of the iceberg. > > Can we not delegate these decisions to the extended profiles ? And not put anything in the "core spec" about updating signatures? I'm fine with that, if other people are (particularly since EPM was the chief driver for these compound operations in the first place). > I thought we agreed that only simple "Content" and "Signature" >TimeStamps would be supported by core ? Those are options on the Sign protocol. I think we're now talking about the Verify protocol. And these "updated" signatures aren't necessarily time-stamps, right? They might just mean the same signature with CRLs added to it, or something? I'm just pointing out these are slightly different things. > If you want to support a TimeStamp other than the 2 Trevor has >already defined in section 3.4.4, let's do so, and call it exactly what >it is and give it it's own response elements as required ... ALL PART >OF CORE and clearly in scope. Personally, I don't want to do that. All that -X, -X-L stuff is complicated and specific to the ETSI work, I think it more properly belongs in a profile. 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]