Fwd: RE: EPM postmark

[Trevor Perrin <trevp@trevp.net>]

Forwarded to the list from Ed -

Trevor

>Date: Wed, 02 Jul 2003 16:33:42 -0400
>From: Edward Shallow <ed.shallow@rogers.com>
>Subject: RE: EPM postmark
>To: 'Trevor Perrin' <trevp@trevp.net>, 'Gray Steve' <steve.gray@upu.int>,
>  dss@lists.oasis-open.org
>Cc: roger.mccune@canadapost.ca
>
>Hi Trevor,
>
>    Further commentary attached. Please (Steve or Trevor) post to list on my
>behalf.
>
>Cheers,
>Ed
>
>
>-----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>
>
>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>
>
>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.
>Again, I believe DSS still has a challenge of differentiating itself. I also
>contend that the EPM gives it a good start.
></ed>
>
>
>Trevor