EPM postmark

[Trevor Perrin <trevp@trevp.net>]

Hi Ed, Steve,

I think I understand the EPM postmark now, tell me if you agree with this:

It's often difficult for relying parties to validate certificate paths and 
signatures.  Protocols like PKIX's SCVP and W3C's XKMS, and DSS for that 
matter, are being invented to offload these burdens.  If you have a working 
PKI, then these servers should be able to track down the appropriate 
revocation/validity info.

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.  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.  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, 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