Subject: RE: SCVP-01

From: "Waters, Stephen" <[email-masked]>
Date: Thu, 26 Aug 1999 10:25:00 +0100

From a VPN point of view....

I don't see the need for SCVP for VPN Security Gateways (most of which have
the resource required to role their own validation), or for VPN-enabled
laptops.  

I guess if you had some tiny thing will limited mem/power, you may want it
to use something else (other than certificate processing) to enable trust.

This can be done by asking a globally reachable SVCP server to help you
understand that nasty certificate thing, or you just don't use them in the
first place.

For remote-tiny things, they have the ID of the server they need to connect
to, so all they really need is the servers public key. 

This seem another good application for the 'private public key' setup where
the client is only loaded with its private key, and the public key of the
server.  You would need to live with the risk of the server key
changing/being compromised and spoofed, but that doesn't seem so bad.

I can see that SCVP may be useful in linking complex user policy to
certificates, particularly at the application level. 

Would it not make good sense to role this functions in with OCSP? 

Steve.

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]]
Sent: Wednesday, August 25, 1999 10:23 PM
To: 'Don Schmidt (Exchange)'; [email-masked]
Subject: RE: SCVP-01

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

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

> -----Original Message-----
> 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,
> 
> 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
>