Time-stamping & signing protocol

["Nick Pope" <pope@secstan.com>]

Thanks Trevor,

As a co-chair I feel somewhat obliged to look for something that meets both
concerns.

My understanding of Ed's concern is that there is something which is clearly
identifyable as the "XML time-stamping" coming out of DSS.

My concern is that we do not define something that has unnecessary
differences between XML time-stamps and other signing services provided by
DSS - firstly so that we do not waste time addressing issues from the two
perspectives, and secondly so that implementations can be use as much in
common as possible.

I suggest that both concerns can be met by using a profile of more generic
protocols and syntaxes which specifically addresses the requirements of
Time-stamping, and also to include in the protocol an indicator (DSS service
type) that the purpose of the request is for time-stamping.

Nick

...
> Larger changes -
>
>   - It assumes the Signing Protocol will be used for
> time-stamping.  I know
> Ed disagrees, but for the moment he's outvoted by me and a co-chair
> (congratulations Nick!).
>
>   - Discussions of time-stamping and authentication were cut, as these
> didn't bear on the protocol but were of a tutorial nature summarizing
> different authentication methods (old 3.3.4) and time-stamping rationales
> (old 3.2.2).  I figured these were unnecessary, and this document should
> just focus us being a target for protocol design.
>
>   - "Intended Audience" added per Tim's request
>
>   - "Signing Policy" and "Verification Policy" were renamed "Implicit
> Parameters" with the text: "These parameters, and any others that aren't
> explicitly dealt with, are implicit in the URI at which the
> client accesses
> the server."  Calling them policies was a disaster.  Does this work?  On
> the con-call was there mention of something more WSDL-specific?
>
>   - On the Verifying Request, there's a new "Request for Updated
> Signature", where the client asks the client to "update" the signature
> after verifying it by adding a timestamp, or validation info, or
> whatever,
> with the exact details determined by the "implicit parameters".  This was
> intended to subsume EPM Verify / ApplyPostmark, and the old 3.7.4 and
> 3.7.5.  I know we're still thinking about this, but I wanted to put in
> something, even just a placeholder.
>
>   - "Signature Verification Steps" added per Andreas and Juan
> Carlos' request
>
>   - Notion of "profiles" was elaborated: "The request/response protocols,
> signature formats, and bindings, can all be profiled.  A combination of
> these profiles is an Application Profile that can be used to address a
> particular use case.  DSS server or client implementations will be
> compliant with particular application profiles of DSS, not with DSS
> itself."  Hopefully this clarifies the ways we were using the word.
>
> 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