RE: [dss] Compound operation Verify & Sign

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

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 ?

   I thought we agreed that only simple "Content" and "Signature" TimeStamps
would be supported by core ?

   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.

   ... else let's leave it for the profiles. The worse case scenario is
doing half the job.

It seems that the question you asked me to post several months ago basically
asking "Which TimeStamps is DSS intending to support" 
ref http://www.oasis-open.org/archives/dss/200309/msg00066.html and related
responses has not been adequately answered or should I say finalized.

I thought that section 3.4.4 of the lastest schema spelled out the 2
timestamps we intended to support. Way back then I thought this was an
appropriate split as the -X, -X-L, and -A advanced timestamps are fairly
complex and perhaps belong in an extended profile. These TimeStamp types are
complaint with the EU Directive and maybe some European DSS implementors
would feel they needed to do this.

You cannot however start strategzing how you would "freshen" timestamps
without at least assessing what ETSI's monumental piece of work has to
offer. Again, if you want to go there, let's do so. Otherwise this is in the
domain of the specific extended profile, and don't try to second-guess what
it would like. Especially if you don't analyze it first.  

Ed



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

At 06:28 PM 11/4/2003 +0000, Nick Pope wrote:

>Ed,
>
>Can I repeat that how the Options and Outputs elements are described is 
>that they are structures specified in the Core but selected as required 
>by profiles.
>
>As the specification is currently written, the Optional elements 
>defined in the core are NOT required to be supported by all profiles.  
>The just provide generally useful components that can be used by profiles
as appropriate.
>
>Whilst there may be different Options for the different type of update 
>that is required for a signature, I still believe that it is worth 
>defining in the common "core" specification, the syntax for a signature 
>element that may be used by all the different profiles that produce an 
>updated signature.  I agree how the server produces the signature and 
>it's content is dependent on the profile, but if we define a common 
>"bucket" into which updated signatures are handled the client does not 
>need to be concerned about these details and use a common approach to
handling the updated signature.

Currently, we have a <dss:Signature> element for returning signatures.  This
can contain a signature (whether XML-DSIG or a binary format like PGP or
CMS), or it can "point" to one (so that if the signature is being returned
embedded in a signed document, the <dss:Signature> can just indicate it).

So I guess we could re-use this element for this bucket, something like:

<dss:UpdatedSignature>
   <dss:Signature>...</dss:Signature>
</dss:UpdatedSignature>

Would that work?

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
.