RE: SCVP-01

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

May I add my humble observations - On the box again Alan :-) 
As we all know ( and I will use LDAP as an example) that the total basis
for LDAP was that X.500 was to complex and slow in terms of "protocols"
- And what was missed in the debate is that X.500 is about object
oriented name based transaction systems that applies distributed
management, distributed access controls, authentication distributed
knowledge, etc -  And by the way it also has three protocols for access,
distribution and replication with the information model.

	LDAP is founded on the X.500 directory information system
standards and some have implemented LDAP servers (non distributed desk
top style servers) with a very basic X.500 object model - And some have
built large scale load balancing, multi master, fault tolerant
infrastructure directory services 10's of millions of entries -
distributed, etc, etc that deal with global backbone issues, etc eg
International Orgs, etc. 

	Reality
	LDAP code base = 230kb appx
	DAP code base - (with 50% provided by an ASN.1 compiler -
automatically) = 130-KB
	X.500 full blown with a database 20-25mb (smaller than some word
processors!).

	Lesson - it took three years to re invent a protocol that was
invented 10 years earlier. The arguments abouts LDAP/X.500  size,
complexity, lightweight etc have evaporated from hype into the reality.
ie. can build a "just a protocol" that zero utility without a service
processing and information model - or one can build an information
system (with protocols)  that has commercial infrastructure utility.



	OCSP - the semantic of the protocol is to get a trusted response
from a trusted entity to validate a cert - 
	With all the bugs out of it and making sure the OCSP server can
scale, connect to large scale directories, works with operational and
busines policy elements - etc , the protocol and the distributed
information service (the directory, PKI/CA and business elements)  that
supports the protocol now has a wider commercial utility.

	eg. at the TCP/IP level the protocol issues was comms/networks.
At the application protocol levels, the issues are NOT comms - there are
the semantics of the transaction(s), the processing and the information
needed to support such ie - the design is a service issue with the
protocol being trivial.


	I would have hoped that using an argument - that a small
lightweight, trivial or nanotomic client that cannot validate a
certficate needs  Yet Another Protocol (YAP) is a debate not worth
having. eg. When that protocol when used by millions of mobile clients -
has to be supported in a sercure/pki directory distributed infrastucture
that underpins a commercial business model and investment. The issue
about the client protocol is about 0.0000000000000001% of the problem.

	ie lets have a new type of telephone call control  protocol ? -
but should we not see what dependency there is of this  in the telephone
system.

	If a client has to do a trusted transaction and sign and encrypt
as well as check and validate -the maths of PKI why cant it use OCSP?.
Is the semantic, functionality and processing of OCSP wrong?

	The best way to debate the YAP issues is with reality.

	ie (hypothetically)  SCVP and its server code is only 5 bytes
wheres OCSP  is a whopping 20kbytes - for the same functionality. That
might be worth investigating.. :-)) 


	Customers with tens and hundreds of databases - where that have
to replicate things to everywhere dont want more of the same - as they
get with LDAP servers.

	Customers who build PKIs are using distributed directory
infrastructureand policy based OCSP services  want stability in that - 
	Yet Another Protocol, with yet another PKI information model and
Yet Another Database  with possible replication expence is not
progressing things.

	 
	This YAP for the sake of YAP -because the the last YAP is to
big, slow and complex - is not useful . And "yet another database" for a
specialised function is also being taken off the customers buying list.

	Can someone list the functional and trust differences between
SVCP and OCSP to see what has value SVCP has?


	Thank you all for putting up with my own personal views.

	regards as always alan


> -----Original Message-----
> From:	Michael Zolotarev 
> Sent:	Thursday, August 26, 1999 12: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.