Subject: RE: SCVP-01

From: Alan Lloyd <[email-masked]>
Date: Tue, 31 Aug 1999 17:21:23 +1000

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. 

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

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

	Just my own views - but I do see a lot of customers and
operational systems :-)

	regards alan

---

From: "Peter Williams" <[email-masked]>
Date: Tue, 31 Aug 1999 06:54:30 -0700

Speaking as an security engineer, reading the communities
SCVP review material:

(a) SCVP is an example of a server-side processing; there
have been objections to that idea, per se, in PKIX,
on telco and moore's law grounds, and on the grounds
that cheap/simple devices are soon to be no more.

(b) SCVP is involved with cert policy handling, and the
remote handling of policy has been been objected to.

(c) SCVP is involved in path construction, per relying-party,
and the directory-manufacturers (Novell, for one) seem to
envisage problems building Internet-scale solutions.

(d) SCVP is mainly an information object specification,
and should be reusable in alternative application contexts
(e.g. LDAP, and DCS).

(e) some have suggested that we confuse the semantics
of OCSP (delivery of status of the certificate record
in the certificate management repository), with
SCVP's delivery of validity status of a given chain.

I was disappointed in the Microsoft message: other
parties in Microsoft are more properly supporting
delegation of policy handling to policy servers. There
is an IETF WG dedicated to the framework for delegation, and
SCVP should be seen as consistent with that general
effort, in relation to its behavior of enabling
a server to handle the relying-parties automated
policy decisions concerning path construction, and
path processing.

I was disappointed by the Novell message: I would have
expected directory folk to leap at the chance to have
servers, or remote clients gatewaying SVCP to
LDAP(s), engage in searching out certificate paths between
two nodes in a DIT. SCVP is not intended to
be a directory protocol. But, the required directory
need not be a enterprise-class solution: SCVP implementations
may exploit scalable multicast conferencing directories,
or secure-DNS, and just avoid client/server designs.

Carlisle's ambiguous message should be dealt with by
the reference to IETF Policy WG. Delegated processing
to policy servers is something which many customers/vendors
are requesting. This is particularly true at
the IPSEC level. There is a long tradition of using
third-party servers to manage bilateral security contexts
in the layer 3 world.

DCS. There was consideration of using DCS as the vehicle
by which to introduce validation checking into PKIX: we
were halted in our tracks when the authors required things be
tied to the ISO NR framework.  Sensibly, Ambarish heeded the
simplicity goal, and chose not to be tied to a heavy-weight
concept.  We can recall, that DCS extension can
easily wrap the SCVP ASN.1 info object and thereby incorporate
the standard validation protocol into DCS, for the NR-grade
certificate handling. Presumably, the NR requirements
will add to SCVP requirements for remote path processing,
as to-be-specified in the DCS draft.

OCSP: the status of a certificate record in a repository
is the certificate issuer's very narrow view on the world.
SCVP looks at the relying-parties view, and asks the question,
"for a path of my choosing, and policy constraints
of my selection, is the user certificate valid in that
context, and the context of previous transaction knowledge
available to the policy/validation server?". Confusing
cert status with path validity will get us nowhere; the
whole point is to separate these, so that relying-party control of security
context formation is obtained, removing mandatory issuer-based controls and
consequential over-dependence on
critical status servers.

Offline Processing by simple clients: there is a spectrum
of router equipment; from that with 0 persistent memory,
cheaper models which can perhaps store a small db of trusted keys on a 40M
PCMCIA drive, to high-end stuff. Clients must be
able to form contexts in the absence of policy/SCVP servers,
when they can at least rely on previous chain validation,
as stored in the trusted key cache.  Details for this
design were specified in PEM; its nothing new. Noone
is suggesting that SCVP server has to be pinged each and
every time a security decision is required, unless the client
is  really dumb agent of the highly-controlling CA (Blacker/Caneware like),
or memoryless.

Policy WG, and reuse: I would like to see the SCVP
specification take component form, enabling its
object to be reused in the extension mechanisms of other
suitable value-adding services, including CMP and DCS. Once
this is achieved, Id like to see the ability of PKIX-LDAP
store the SVCP result as an attribute, to instrument
the write-through caching; but more on this later,
perhaps.

Peter.

> -----Original Message-----
> From: Alan Lloyd [mailto:[email-masked]]
> Sent: Tuesday, August 31, 1999 12:21 AM
> To: 'Ambarish Malpani'; 'Salz, Rich'
> Cc: [email-masked]
> Subject: RE: SCVP-01
>
>
> 	snip

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 31 Aug 1999 09:29:08 -0700

>and interoperability when both technologies are used in the same

Yes, that's probably true. SCVP doesn't do any of that. This seems like a 
red herring.

>less configuration and more capability and trust  -  to see what the

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.

Or are you saying that none of the SCVP features are desired by anyone?

>ignore them and produce another YAP with optional extensions. that wont

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.

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.

--Paul Hoffman, Director
--VPN Consortium