RE: EPM postmark

[Trevor Perrin <trevp@trevp.net>]

At 04:33 PM 7/2/2003 -0400, Edward Shallow wrote:

>-----Original Message-----
>From: Trevor Perrin [mailto:trevp@trevp.net]
>Sent: June 30, 2003 6:38 PM
>To: Edward Shallow; 'Gray Steve'; dss@lists.oasis-open.org
>
>
>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.
><ed>and ETSI 101 733/903, and RFC 3126, and DVCS, etc ...)</ed>
>If you have a working PKI, then these servers should be able to track down
>the appropriate revocation/validity info.
>
><ed>
>... But perhaps (likely) independently of the signature verification, and
>timestamping results ...
></ed>
>
>However it's reasonable for a signer to procure responses from a cert-status
>protocol (e.g. OCSP, SCVP, RTCS) and
>
><ed>
>... onus on signer who now has to coordinate service calls across service
>providers in order to achieve objectives ... what happens if they neglect to
>call a pre-req service that weakens or worse invalidates the strength of
>their evidence ? ... many of the service providers are already governed by
>existing standards ...
></ed>
>
>attach these to the signature,
>
><ed>
>... as signed or unsigned attributes ? I believe this is within the domain
>of DSS ... I believe you would want to avoid insertion of signature
>attributes in too many divergent ways, a noble objective for the protocol
></ed>
>
>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
><ed>
>   - that the signature was applied under the auspices of a SignaturePolicy
>(ID, hash, and algo)
>   - that the response from the ValidationAuthority was signed
>   - that the returned signature from that ValidationAuthority was verified
>   - that the timestamp response signature was verified
>   - that evidence of all the above was logged and will be maintained for a
>suitably long period of time
>   - that protection from key compromise will be maintained over that
>extended period of time
></ed>
>
>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.
>
><ed>
>... Not if you subscribe to, for example, ETSI 101 733, XAdES-C, RFC3126,
>etc ...
></ed>

Here's my confusion - all the above references talk about doing *both* of:
  - adding certificate and revocation data to a signature
  - time-stamping it

My impression was that EPM, when asked to Verify/ApplyPostmark, *only* 
applies a timestamp to the signature:

<element name="ApplyPostMark" type="boolean"/>
<!--
Replaces the need for a separate VerifyPostMark verb. This indicator 
instructs the
EPM Service to insert a timestamp token within the incoming signature
using the native TSA timestamp service.
-->

Thus, it seemed to me that EPM was non-standard, since EPM was using a 
time-stamp to mean not only "this data existed at time T", but "this data 
was valid/non-revoked at time T".

It's likely I'm misunderstanding EPM, so I hope you can clarify.


>I could imagine situations where the signer would want to use one TSA but a
>different cert-path validation service.
>
><ed>
>I can't. This is a daunting task to understand, let alone implement.
>Commercial availability of TSA and OCSP Services are scant to non-existent.
></ed>
>
>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,
>
><ed>
>... This is exactly what ETSI 101 733/903 does. If you are not proposing to
>follow suit, then what is being proposed ?
></ed>

Yes, that's what seems to me the standard approach.  It seems that EPM is 
deviating from this approach, by using the timestamp token to make a 
statement about the validity of the signature.  So I was pointing that out.

I just wanted to confirm my understanding of EPM's Verify/ApplyPostmark, so 
we can investigate how such an operation would be implemented using the DSS 
framework.



>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".
>
><ed>
>This is the domain of SignaturePolicy ... See CommitmentRules, etc ... This
>kind of flexibility is already built into the exisiting published standards.

Are you saying put those kind of things into an RFC 3161 
TimeStampToken?  To me, that sounds like abusing the concept of a 
TST.  According to RFC 3161, "The TSA is REQUIRED[...]not to examine the 
imprint being time-stamped in any way", which seems to imply that a TST 
should be used purely for time-stamping, not for conveying anything else 
about the timestamped data.


>Again, I believe DSS still has a challenge of differentiating itself. I also
>contend that the EPM gives it a good start.

I'm not sure what he have to differentiate ourselves against. But I agree 
that EPM has a lot of good ideas we should build off of, and that's it's 
important for us to get a solid understanding of EPM before going 
forward.  Thanks for helping explain it.

Trevor