RE: [dss] Compound operation Verify & Sign

[Trevor Perrin <trevp@trevp.net>]

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