RE: SCVP-01

[Michael Zolotarev <mzolotarev@xxxxxxxxxxxxx>]

A short comment:

I've been closely looking into the WAP forum for the last couple months.
Whatever commercialized and market-hyped the developments are there, it
appears that a lot of the 'little box' vendors are joining the WAP forum.
The list is impressive and growing fast. So it may worth considering their
needs when contemplating about real world's business cases and requirements.

Being essentially a browser-based platform, a WAP device is driven by the
application which is run by the WAP gateway/app_server. The gateway
presumably would not have any troubles with performing PKI operations. 

The WAP is not the whole world, of course. However, I feel that there is a
solid trend to produce either a "simple small device", or a
"powerful_yet_small device". A 'simple small' device would use WAP or
similar approach, and the other group would presumably be able to handle PKI
itself. Communications, by the way, is not a problem for either group.

SCVP, as it seems, is trying to address the problems of what can be
described as a 'middle group'. I'm not convinced that group has its
evolution niche (except if you are in Kansas state :)).

Thinking about WAP (and other ultra-thin solutions), the question is which
protocols would be required by the gateway/app_server. Would SCVP help
there, or OCSP and other existing protocols suffice?

This is just my personal, marked-influenced opinion. Standard disclaimer
follows here.

MichaelZ


-----Original Message-----
From: Bob Jueneman [mailto:BJUENEMAN@novell.com]
Sent: Thursday, August 26, 1999 10:46 AM
To: carlisle.adams@entrust.com; ambarish@valicert.com
Cc: donsch@Exchange.Microsoft.com; ietf-pkix@imc.org
Subject: RE: SCVP-01


I might not agree with Microsoft all that often, but in this case I do. :-)

Maybe SCVP would be of some value in a digital phone that was somehow
involved in processing certificate chains -- it would meet the criteria of
presumably small footprint, yet have outbound network connectivity.  
Other applications, such as pagers, pay-per-view set top boxes, 
would not seem to have the necessary connectivity.

In addition, having been rather deeply involved in the cellular industry 
for a while, I would be concerned about the burden such an approach would 
place on the central servers. Generally, I would like to offload as much 
of the processing to distributed silicon, where the MIPS and the memory 
are much more available and less expensive, rather than burdening the
central infrastructure.

I would be interested to understand real-world examples of where there is 
a significant business case for this functionality. No offense intended, but

so far, I haven't seen that it is worth the WG bandwidth, frankly.

Bob

>>> Carlisle Adams <carlisle.adams@entrust.com> 08/25/99 03:56PM >>>
Hi Ambarish,

> ----------
> From: 	Ambarish Malpani[SMTP:ambarish@valicert.com] 
> Sent: 	Wednesday, August 25, 1999 5:23 PM
> To: 	'Don Schmidt (Exchange)'; ietf-pkix@imc.org 
> 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.
 
Observation #1:

Don's "group" seems to represent a reasonable fraction of the world's
population...  :-)

While I believe they exist, my impression is that we're still waiting to
hear from this "particular set of users" to confirm that the functionality
embodied in SCVP is a legitimate requirement.  Don's "group" has stated that
they don't need this (at least at the moment).  Do we have concrete details
regarding who does need this?

> 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.
 
Observation #2:

It strikes me that the above two paragraphs are somewhat antagonistic.  If
I, as a client device, "can choose to either use the service or do all the
work myself", then there is no possibility of consistent / centrally-managed
cert policies.  On the other hand, if devices do not have this choice (i.e.,
if devices MUST off-load the validation work to the central server), then
this itself is a cert processing policy that must be implemented (correctly)
on every client desktop.  What problem, therefore, does SCVP solve?


[Note:  don't take my observations above as necessarily "for" or "against"
this functionality.  I would just like to make sure that we, as the PKIX
group, are clear on what this protocol is trying to achieve and who the
target audience is.]

Carlisle.