Subject: RE: SCVP-01

From: "Don Schmidt (Exchange)" <[email-masked]>
Date: Tue, 24 Aug 1999 13:00:08 -0700

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.
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.

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.   

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.

Don Schmidt
Program Manager
Microsoft Corp

 -----Original Message-----
From: 	Ambarish Malpani [mailto:[email-masked]] 
Sent:	Monday, August 23, 1999 11:58 AM
To:	[email-masked]
Subject:	SCVP-01

Hi Guys,
    I noticed that there hasn't been too much discussion of SCVP
after the 01 draft came out. Paul and I have got a few comments
offline, but there hasn't been much on the list. A few people
expressed interest in getting implementations and I was
wondering if we have already gone through the major changes
stage and are winding down the changes that will be made to
the spec.

Comments?

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833

---

From: "Ambarish Malpani" <[email-masked]>
Date: Wed, 25 Aug 1999 14:23:25 -0700

Hi Don,
    Thanks for the feedback. I find your reaction to SCVP
perfectly reasonable. It will serve an important function for
a particular set of users and your group might not be one of
them.

Let me again specify the main benefits of this protocol, as I
see it:

- Allows applications that want to use public key cryptography
to leverage the Public Key Infrastructure (PKI) without needing
to understand its full complexity - SCVP lets you use certs
and does the work of chain building, policy management and
cert validation for you. This is both an issue of footprint
size/processing power *and* the engineering work that needs to
be done to understand PKIX.

- It allows for consistent/centrally managed cert policies,
rather than requiring the policies be implemented (correctly),
on every client desktop, across various different applications.

In some sense, you can think of the SCVP server as a remote
COM object, that is providing certain services for you - you
can choose to either use the service, or do all the work
yourself.

Don't know if this will make you look at it differently, hope
it does.

Regards,
Ambarish

> From: Don Schmidt (Exchange) [mailto:[email-masked]]
> Sent: Tuesday, August 24, 1999 1:00 PM
> To: 'Ambarish Malpani'; [email-masked]
> Subject: RE: SCVP-01
> 
> 
> Ambarish,
>