[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SCVP-01
Hi Michael,
Thanks for the mail. The SCVP model is exactly like the WAP
model. The SCVP server is your 'WAP gateway', that does all the
stuff that needs to be done with the certificate. The 'simple
small device' simply passes the cert to the SCVP server and asks
it whether it can rely on this cert for a particular application.
Am I missing something?
Regards,
Ambarish
P.S. Didn't quite catch the Kansas thing.
---------------------------------------------------------------------
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: Michael Zolotarev [mailto:mzolotarev@baltimore.com]
> Sent: Wednesday, August 25, 1999 7:31 PM
> To: Bob Jueneman; carlisle.adams@entrust.com; ambarish@valicert.com
> Cc: ietf-pkix@imc.org
> Subject: RE: SCVP-01
>
>
> 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.
>