RE: [dss] EPM postmark

[Trevor Perrin <trevp@trevp.net>]

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