RE: SCVP-01

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

Interesting views - 

> -----Original Message-----
> From:	Paul Hoffman / VPNC 
> Sent:	Wednesday, September 01, 1999 2:29 AM
> To:	Alan Lloyd; ietf-pkix@imc.org
> Subject:	RE: SCVP-01
> 
> At 05:21 PM 8/31/1999 +1000, Alan Lloyd wrote:
> >         snip
> > > Yes, we could put in a bunch of changes in OCSP to make it
> > > work, but you would end up changing the semantics of a large
> > > part of OCSP.
> > >
> >         its best to add a few features to a trusted transport that
> >serves a common operational function (cert status and validation)
> than
> >reinvent the whole box and dice again - re key management, protocol
> hddr
> >formats, routing references, etc, etc - and also introduce
> compatibility
> >and interoperability when both technologies are used in the same
> >operational system.
> 
> Yes, that's probably true. SCVP doesn't do any of that. This seems
> like a 
> red herring.
> 
	But SCVP is signed - the same as OCSP - and that needs key mgt
and certs, etc.. So why have two "trusted protocols" for dealing with
cert validation and status and all that gets carried with it for the
customers to deal with.

	I once heard a strory which was wrong of course which said that
OSI (and X.500) was complex and slow because of its options proposed at
each layer of functionality .. This of course has over time proved to be
wrong. 
	In this case of OCSP/SCVP we have "simple protocols "
duplicating many common features thus causing more configuration and key
management effort - for product developers, suppliers and customers -
needlessly

	Why in vent a new protocol when we can just process a protocol's
parameter?. 

> >         One only has to think of the customer and what they want...
> >simpler systems, less code changes, less protocols, less databases
> and
> >less configuration and more capability and trust  -  to see what the
> >logical answer is..
> 
> Yes, that's probably true. Do you think that adding the SCVP
> functionality 
> to OCSP would not involve more complicated systems and more code
> changes? 
> Of course, it is one more protocol, but if you're talking bits on the
> wire, 
> the SVCP request and response are carried on the same protocols as
> OCSP. I 
> don't know what you mean by more databases or more configuration. If
> you 
> want to get the functionality of SCVP in OCSP, you'll need to have the
> same 
> databases and configuration, and the same capability and trust.
> 
	May I explain the diffrenece between "the bytes on wire" - a
protocol spec and an operational product.
	Those who make the protocol will require the end systems to have
configuration of endpoints, time outs, stack references, key management,
etc and if OCSP is used as well those will need similar information -
and operational management.

	So why repeat the implementation for the support mechanisms for
YAP when one can add a few parameters and the application processing
only for an existing protocol?

	It one of product packaging, ease of configuration and
operational effort and of course - dealing with what customers want
(simpler interoperable systems) and not inventing YAP because it sounds
like  a good R&D project.


> Or are you saying that none of the SCVP features are desired by
> anyone?
	No - I just think this can be done with additional fields in
OCSP - rather than just another YAP... I n this discussion - what sort
of stystems do you build. How do you relate trust, risk, reliability and
key management effort  -- its like LDAP servers -
	replicate everything to everywhere = lower trust, low integrity
and operational cost.
	ditto systems that use OCSP in some places and YAP (SCVP) in
others = lower trust, low integrity and higher operational costs.


> >         Why does OCSP and LDAP have extensions... Its not so we can
> >ignore them and produce another YAP with optional extensions. that
> wont
> >be used...
> 
> Correct. OSCP extensions can be used to extend OCSP. What we are
> proposing 
> does not fit into the semantics of OCSP. There are two possible
> solutions: 
> extend the semantics of OCSP, or create a different protocol that does
> what 
> you want without forcing a change in an existing protocol. SCVP uses
> the 
> latter approach.
> 
	Extend the semantics is easier - that just requires an
additional definition.

	PLEASE NOTE - any extension to any protocol changes its
semantics as well as its syntax ..

> If you think it should use the former, I extend the same suggestion
> that I 
> extended to Mike Myers: do the work of changing the OCSP spec to
> include 
> the SCVP functionality and show it to the group. I sincerely think
> that you 
> will not find it easy, and that OCSP developers will find it as hard
> (or 
> even harder) to shoehorn in your changes to OCSP extension mechanism
> as 
> they would to use the SCVP request and response format. I could be
> wrong 
> about this, and would be happy to admit so if your draft looks easier
> than 
> SCVP. But Ambarish and I really looked at this before we created our
> own 
> format.
	All I can say if its difficult to extend OCSP then why have
extensions - see LDAP extensions

	There does not seem any techical  or engineering reason why this
extension cannot be done... and it would be much better for those on the
receiving end - customers...
	The implementations of extensions can be optional by the way...

	regards alan
	regards alan


> --Paul Hoffman, Director
> --VPN Consortium