apologies and comments on SCVP

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

Dear all, I was a bit soap boxish on my last email - apologies. May I
submit some personal comments on the draft. The detailed syntax of the
protocol is not of concern - that is always the easy bit. But the
approach of the PKIX group to having "standards" that people want to
build systems with, does.

The first issue is one of qualification of new protocols - well there
seems no engineering substance to them. The second is the logic that
promotes them..
eg.
1. A "process" is "complex" abstract statement ... eg X.500 directories
and processing certs..
2. We need another protocol to make the client simpler - but it is a
YAP.
The client now through this protocol (the YAP)  can now arry and do all
what the other protocols do..So it has by definition got more complex!

The issue is that why doesnt the group seek to provide one standard..
and I know this has been raised before.

My personal comments on the draft follow.

*****************

Abstract

The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about the
certificate, such as whether or not the certificate is valid, a chain
to a trusted root, and so on.

AL: Please add: However, it the responsibility of the client (using out
of band mechanisms to validate the protocol signatures and keys of the
server - or not) to trust the server it requests this service of. In
addition if the client asks the server for all the path and validity
information such as CRLs, etc - the client could have used LDAP or DAP
for this purpose. Also the client will have to be fairly "complex" to
understand and process all its PKI information anyway.

--

1. Introduction

Certificate validation is a difficult problem. 

AL:I don't believe these "abstract" statements are a good rationale for
developing YAP!  Validation does rely on PKI capability so its not quite
right to say that because a key management function is more difficult
than a protocol definition - another protocol should be developed..

--
If certificate handling s to be widely deployed in a variety of
applications and environments, the amount of processing an application
needs to perform before it can accept a certificate must be reduced. 
There are a variety of applications that can use public key certificates
but are burdened by

AL : re ..read reason for LDAP vs X.500 "is big and complex" - we need
to re invent...!!! 
Can those proposing new protocols (YAPS) instead of using "abstract
words" like  "burden" , "complex", "overheads" and what 'applications
really want to do" cite product and development references, reality,
code sizes, performance reports and benchmarks.

--
the overhead of validating the certificates when all the application
really wants is the public key and name from the certificate,
 
AL: what is this "overhead".. someone said it was in DAP which is half
the size of LDAP!
--

and a
determination of whether or not the certificate may be used for a
particular purpose. There are other applications that can perform
certificate path validation but have no reliable method of obtaining a
current chain to a trusted root.

AL: How do we know this SCVP is trusted to the root.? What trust is
there in a server, when this spec in facts describes a zero trust
server.

AL: The majority of engineering in protocols, specifically applications
protocols is dealing with the information model they support (eg. PKI),
getting the transaction reliable ( time outs, sequences, recovery) and
if signed operations are used, getting the trust and key management of
them operational on a large scale. 
As we read through this spec, it seems that most of the transaction,
information (PKI) and key management issues of the protocol are covered
off in the OCSP spec - Is all we need to service the delta's of SCVP, is
a few extensions in OCSP to deal with: 
a) Asking for paths and crls in the response and:
b) the ability for a client to send its root information to the server?


----

1.1 SCVP overview and requirements

The primary goals of SCVP are to make it easier for applications to
deploy systems using a PKI and to allow centralization of administering
PKI policies. 

AL: This goal is not really met is it. Simply because SCVP permits the
client to do all its validation by pulling certs and crls. I assume when
people invest in a trusted protocol like this - they would be somewhat
exposed if they did not implement all of it. See "supplier and consumer
risks" section not written yet! In addition, the server end is a major
variable - trusted, untrusted, gives back certs or validates them, etc..

---

Parts of SCVP can be used by clients that do much of the
PKI processing themselves and simply want a useful but untrusted server
that will collect information for them. Other parts can be used by
clients that have complete trust in the server to both offload the work
of certificate validation and to ensure that policies are enforced in a
consistent fashion across an enterprise.

AL: Assumptions are made here - that in a mixed configuration of SCVP
clients talking to SCVP servers that in turn use OCSP upstream -
inconsistencies will apply.
Assumptions are also made that this simple client knows what the cert
path/validation system topology is - back to the message originators
root. This is somewhat difficult - (a new abstract word!)

A SMALL POINT TO THE PKIX GROUP... Is useful for the group to invent
protocols of similar transaction, information model (PKIs) and trust
(signed req/resps) facilities that do not inter-work or cause major
operational incompatabilities.


---
Untrusted SCVP servers can give client the certificate chains needed
for path validation. They can also give clients revocation information
such as CRLs and OCSP responses that the client can use in the client's
path validation. These services can be valuable to client systems that
do not include the protocols needed to find and download all of the
intermediate certificates, CRLs, and OCSP responses needed for the
client to perform complete path validation.

AL: The first para of the spec was: we need another protocol because
cert validation is complex and obviously OCSP was too complex to add a
few extensions to.
However, we now have the "simple" client validating everything including
upstream OCSP responses which can be signed I assume.. Therefore the
simple SCVP client has to validate the keys/sigs of the OCSP severs? And
their certs...
I do detect a dilemma and a paradox forming here.. 
Ie we need a simple protocol because a complex one is too complex but
the simple one can carry complex protocols for the client to process -
but that does not matter!

----
Trusted SCVP servers can perform full certificate validation for the
client. If a client uses these services, it inherently trusts the SCVP
server as much as it would its own path validation software (if it
contained such software). There are two main reasons that a client may
want to trust such an SCVP server:

- The client does not want to incur the overhead of including path
validation software and running it for each certificate it receives.

AL: However, it wishes to incur the protocol overhead of dealing with
signed transactions.

-----
- The client is in an enterprise that wants to centralize its PKI
validation policies, such as which root certificates are trusted and
which types of policy checking are performed during path validation.

This is achievable with other protocols such as LDAP, DAP (trusted
directories), and OCSP.


regards alan