RE: SCVP-01

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

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.