RE: SCVP-01

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

> 
> Ambarish,
> 
> Since returning from Oslo, I have discussed SCVP with my colleagues and have
> confirmed the position I presented during the PKIX session.  Microsoft
> currently has no plans to implement SCVP.  We are not aware of any demand
> from our customers for such a protocol; whereas, we have several PKI-based
> applications which must run when the client is offline as well as online.
The question is what can such an application really do in an offline way? 
You can validate a signature etc and then launch some action, create another
document in a work flow, but if you don't leave the virtual reality world, 
the effects of that application become only visible when you get online later.

> But most important, we do not agree with the fundamental justification for
> SCVP.  The primary rationale provided in Oslo was that server-based
> certificate validation is required by small devices which do NOT have
> adequate processing and memory capabilities to locally validate certificate
> chains, but DO have readily available network connections to offload this
> work to a server.  It has been our experience that the opposite is true.
> Devices continually increase in processing power and memory to whatever
> level is required, while connectivity continues to be a problem.
> Applications which require constant (or on demand) network connectivity to a
> supporting server typically suffer performance problems and frequently fail
> simply due to dropped packets or connections.
Processing power is indeed not really the problem 
(comparing a few octets doesn't require a supercomputer).

The interesting point though is configuration management of many clients, 
downloading and maintaining company policies and so on. For example, 
it easy to run a 'dumb' client WITHOUT any local configuration. 
The user has a smart card containing his own information (a signing key/cert)
and a certificate of his trustworthy server with the URL of the server. 

> 
> One might be tempted to negate the connectivity argument if it is believed
> that SCVP is only intended for handheld communication devices which must
> have connectivity to perform their primary function.  However, relying on a
> server will add another network hit for every call and possibly introduce a
> performance bottleneck.  Furthermore, since these clients will need to be
> able to perform rudimentary cracking of at least the end entity's
> certificate, it seems we might better spend our time defining a profile that
> limited the chain depth for such devices.  

One should distinguish between a communication protocol, and what a client
is supposed to do. Having a protocol doesn't mean that a client can implement
whatever appropriate strategy to use or to avoid the usage of that protocol.

If an adminstration requires youn to be present to show a document, 
performance bottlenecks don't count. The adminstration will not come
to your home just because you tell them that you are not able to
come to them. :-) 

If an important application requires online status checking of a cert
(why does OCSP exist??) then you need to be online....  
 
> 
> Finally SCVP introduces additional security problems that must be addressed
> to make sure a rogue server cannot trick a client into accepting an invalid
> certificate or chain.  Locating and authenticating such servers could be a
> significant challenge for highly mobile users.  OCSP & DCS already face
> these kinds of security issues.  Why solve the same problem over and over in
> separate protocols?  If it can be demonstrated that there is a customer
> demand for SCVP-type services, then it would seem prudent to add them as an
> option to an existing server-centric protocol.

I like one element of SCVP, the way to define data objects and high level 
abstract services without directly specifying them in whatever wire format. 

I would like to know what is missing in DCS to support SCV.
DCS works well in an environment of creating and validation CMS documents.
(If no storage of the tokens are needed the request/response do not even need
to be encapsulated in CMS but can just be transfered using something like
SSL/TLS or whetever lower layer protocol that allows mutual authentication.)
(All this is already mentioned in the DCS text, at least in the version that
 I have in my mind).
  
Have fun
Peter Sylvester