Re: DRAFT PKIX WG Meeting Minutes

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

Hi,

I would like to comment one item on the minutes (the content, not the minute item)

> Data Certification Server Protocol (C. Adams-Entrust)
> Peter Sylvester is the new lead editor and a new I-D has been published as
> of this week. Scope has been pretty broad, encompassing features of
> notarization OCSP, SCVP, TSP, etc. So, this is an example of the question
> raised on the list with regard to different protocols for different
> services, or a grand unified protocol approach. Possible options include
> freezing this spec now as an experimental protocol, reduce scope to avoid
> conflicts with other work items and continue as a standard track protocol,
> or keep broad scope and kill other protocols. Denis notes that, from a
> conformance standpoint, bundling would create the need to allow subset
> compliance, since not all clients or servers will need all of the features
> offered by a unified protocol. Discussion explored the dimensions in which
> one may choose to partition protocols, e.g., mandatory use of a server for
> non-repudiation vs. optional use of a server for operations that could be
> performed by a client.

The issue of bundling had been addresses in the initial draft:
A server can provide one or more of the services. 

"A DCS MAY support any subset of the following services: 
Certify Possession of Data, Certify Signature, Certify Public Key Certificate"

A client that desires a specific service need to be configured locally
anyway in order to reach the desired services. The protocol description
is open regarding operational scenarios where different servers 
are used by clients. 

Is local configuration (selection of a an appropriate server) part of
what should be described? There is already a hint in the draft that
explains how to publish the URL of a server in a certificate.

On of the problems that may occur is that a client may just be
configurable to use ONE server (and one transport) for all services.
Poor client, and there are people who are able to write little
proxies to relay requests (a DCS server itself can be such a relay).

Using an identical syntax for requests and tokens of the
different service has an implementation advantadge, you have one common
coder/decoder.  

Besides that, there is a small problem in the syntaxes of DCS and TSP:
They are not compatible with the syntax of CMS SignedData
(the EncapsulatedContent).


Peter Sylvester