RE: SCVP-01

["Peter Williams" <peterw@xxxxxxxxxxxx>]

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:Alan.Lloyd@OpenDirectory.com.au]
> Sent: Tuesday, August 31, 1999 12:21 AM
> To: 'Ambarish Malpani'; 'Salz, Rich'
> Cc: ietf-pkix@imc.org
> Subject: RE: SCVP-01
>
>
> 	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
>