RE: SCVP-01

["Ambarish Malpani" <ambarish@xxxxxxxxxxxx>]

Hi Carlisle,
    Comments below:


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


> -----Original Message-----
> From: Carlisle Adams [mailto:carlisle.adams@entrust.com]
> Sent: Wednesday, August 25, 1999 2:57 PM
> To: 'Ambarish Malpani'
> Cc: ietf-pkix@imc.org; 'donsch@Exchange.Microsoft.com'
> Subject: RE: SCVP-01
> 
> 
> 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...  :-)

I knews Microsoft was big - didn't realize it was that big :-)

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

I have had conversations with people who are interested in this.
Also, we have had quite a few of our customers use our tookit
to do OCSP, but really wanted SCVP-like functionality. Yes, there
are such people, unfortunately, most of them do not read the
PKIX list - they belong to my first group of users - people
who want to user public key cryptography without the overhead
of understanding all of PKIX.

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

I was a little unclear in my last paragraph. The person making
the choice of whether their application does cert processing
itself, or relies on an SCVP server makes the decision while
developing the application. I do not see most applications
giving users the choice of either using a local implementation
of policy or talking to the server. The "on the other hand" case
you are talking about is right on - yes, I am talking about
a cert processing policy, that needs to be implemented (correctly)
on every client desktop - SCVP. However, I am relatively sure
you won't argue that correctly implementing SCVP is quite a
bit easier than correctly implementing PKIX Part 1(2459),
LDAP Op Protocol (2559), OCSP (2560), LDAP Schema for PKIX(2587),
LDAP (1777), ...
 


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

Always a pleasure responding to your clarification mails :-)

> 
> Carlisle.
> 

Regards,
Ambarish