RE: [dss] EPM postmark

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

I am obliged to declare on behalf of my company, Security & Standards Ltd,
that our patent
mentioned earlier includes a variation where a "seal" is issued based on the
validity of a signature and associated certificates.

Nick

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 02 July 2003 04:05
> To: jmessing@law-on-line.com; dss@lists.oasis-open.org
> Subject: RE: [dss] EPM postmark
>
>
> At 10:02 PM 7/1/2003 -0400, jmessing wrote:
>
> > >Depending on the type of service, it might add validation data and then
> > >timestamp, or timestamp as a way of asserting validity, or just add
> > >validation data, in which case the client could then call
> another service
> > >to get a time-stamp.
> > >
> >Or just report the results of a validation event as of a particular date
> >and time under its digital signature, if the relying party will accept
> >this statement as a certification from a trusted third party,
> even without
> >a timestamp.
> >
> >Is this possibility covered somewhere else in the requirements document?
>
> That's kind of what I mentioned here[1] - that the client could request a
> signature on a signature (i.e. a counter-signature), and as a prelude to
> signing, the service would verify the first signature.  The
> countersignature would have a signaturePolicy identifier that means "I've
> verified this [i.e. the countersigned] signature and its
> certificate chain".
>
> The requirements doc doesn't specifically cover this, but allows it.
>
> More recently, we've been talking about having the client request
> a Verify
> operation, instead of requesting a Sign, but with the option for "return
> verification info".  This approach is more congruent to EPM, which has a
> Verify operation with an ApplyPostmark option.
>
> We've also been talking about the service returning more
> conventional types
> of cert-chain validation info, like CRLs or OCSP / SCVP / XKMS / RTCS /
> whatever responses, instead of a counter-signature or time-stamp.  In
> theory it would be good to use a standard, though in practice the
> standard
> situation seems confused right now, so maybe counter-signatures or
> time-stamps to represent a statement by a 3rd-party about the
> authenticity
> of a signature and its cert-path are a worthwhile expedient.
>
> [On a side-note: if you have a time-stamp covering the signature,
> then the
> 3rd-party only needs to vouch for the validity of a cert-path, not the
> whole signature, since it's trivial for a relying party to check that the
> end-entity cert's public key verifies the signature.  That's why I'm
> suggesting that the EPM postmark, which covers the signature,
> could be just
> as well be replaced by cert-path validity info from a 3rd party,
> along with
> a time-stamp.]
>
> [1] http://lists.oasis-open.org/archives/dss/200306/msg00046.html
>
> Trevor
>
>
> You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php