RE: [dss] EPM postmark

["Nick Pope" <pope@secstan.com>]

Juan Carlos & Trevor,

Whilst I have no problem with defining the services in a way so that they
can be decoupled, it should also be possible to provide a single integrated
service that provides all the user needs in a single request.  Significant
cost savings and efficiencies are achievable with such an integrated
service.

Nick

> -----Original Message-----
> From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.es]
> Sent: 01 July 2003 11:45
> To: dss@lists.oasis-open.org
> Subject: Re: [dss] EPM postmark
>
>
> Trevor
>
> See below
>
> Juan Carlos.
> At 16:38 30/06/2003 -0700, Trevor Perrin wrote:
> >
> >However it's reasonable for a signer to procure responses from a
> >cert-status protocol (e.g. OCSP, SCVP, RTCS) and attach these to the
> >signature, to make cert-path validation easier for the relying
> party or his
> >delegated service.
>
> <JC>Yes, exactly and that is why in our service we anticipate this option,
> and this is precisely the reason why XAdES has defined extensions to both,
> add the certpath, crls, ocsp answers AND TIMESTAMPS ON THIS
> MATERIAL..</JC>
>
> It's also reasonable for the signer to attach a
> >time-stamp to the signature, so the relying party can ensure that the
> >signature was made while the cert-path was valid.  An EPM
> postmark combines
> >these 2 things - when the relying party verifies a postmark from
> a trusted
> >EPM on a signature, he knows:
> >  - that the cert-path was valid at time X
> >  - that the signature was made some time before X
> >
> >I see that it's efficient to do both these things in a single protocol
> >exchange, and by only adding a single extra signature to the
> document.  It
> >gives up some flexibility and is non-standard, though.  I could imagine
> >situations where the signer would want to use one TSA but a different
> >cert-path validation service.
>
> <JC>I think you are right: ussers could select one service for
> validation and
> a different TSA for time-stamping his signature; concerning the
> time-stamp on
> the validation data, the service could use his own TSA... </JC>
>
>   And since TSAs and validation services are
> >concepts that are already being designed and deployed, it might
> be better
> >for an EPM service to separately add cert validation info into a
> signature,
> >and then time-stamp it,
>
> <JC>I also think the same. My view is that our service should be
> designed with
> this idea of de-coupling services  in mind</JC>
>
> as opposed to overloading an RFC 3161 time-stamp
> >token with the semantics "the signature this was applied to also has a
> >valid certificate chain".
> >
> >Trevor
> >
> >
> >You may leave a Technical Committee at any time by visiting
> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wor
> kgroup.php
> >
>
> You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php