[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: SCVP-01



I think OCSP's scope is too narrow and that some business segments
actually expected that it was providing a validation service. I don't
have any evidence (that I can reveal) that users require a validation
service but, inasmuch as OCSP is perceived as useful, I think the next
step (of performing the validation) is also useful.

There was some debate about a suitable protocol but it was inconclusive.
SCVP is either a good first cut or a suitable straw man.

> -----Original Message-----
> From:	Bob Jueneman [SMTP: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.
>