OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dss] EPM postmark


Trevor

See below

Juan Carlos.
At 16:38 30/06/2003 -0700, Trevor Perrin wrote:
>
>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.  

<JC>Yes, exactly and that is why in our service we anticipate this option,
and this is precisely the reason why XAdES has defined extensions to both,
add the certpath, crls, ocsp answers AND TIMESTAMPS ON THIS MATERIAL..</JC>

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.

<JC>I think you are right: ussers could select one service for validation and
a different TSA for time-stamping his signature; concerning the time-stamp on
the validation data, the service could use his own TSA... </JC>

  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, 

<JC>I also think the same. My view is that our service should be designed with
this idea of de-coupling services  in mind</JC>

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
>
>
>You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]