RE: [dss] Compound operation Verify & Sign

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

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
.