Subject: apologies and comments on SCVP

From: Alan Lloyd <[email-masked]>
Date: Thu, 26 Aug 1999 23:03:39 +1000

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

---

From: "Ambarish Malpani" <[email-masked]>
Date: Thu, 26 Aug 1999 20:36:45 -0700

Hi Tom,
    Fair question. I think I have tried to answer it before, let
me try again.

There are 2 application classes for SCVP:
1. ClientType1
2. ClientType2

(I have purposely chosen *not* to try and use more descriptive
names for the clients, to avoid digressive discussions).

ClientType1 basically wants to be able to use public key
cryptography (and the PKIX infrastructure), without needing to
understand all of PKIX part1, OCSP, LDAP etc. It is outsourcing
the task of checking cert status, cert expiry, policy management
etc to the SCVP server. The main question ClientType1 is asking
is: "Hey, I got this cert, can I use it for application X?".
The minimal response the server needs to provide is a signed
yes/no. If you throw away all the extra stuff, you essentially
have the client sending in a cert and getting back a yes/no
answer.

ClientType2, is basically getting the server to build all the
chains, get validation responses etc., but checks all the
responses itself - it isn't trusting the work done by the
server, but using it mainly as somebody to offload the work to,
which it then verifies.

My main push is for serving the needs of ClientType1, just
because I believe it opens up PKI to a lot more applications.

Now to get to your main question about what is the difference
between the OCSP and SCVP.

In OCSP, all you are getting is the status of a certificate.
The client *must* build the chain - because it needs to tell
the responder which CA it is talking about. So, OCSP requires
the client to do the chain building, cert date/signature checking,
policy checking etc. The main thing the responder is doing,
is telling you the status of the certificate.

Does this help clarify the differences?

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, August 26, 1999 8:07 AM
> To: Alan Lloyd; [email-masked]
> Subject: Re: apologies and comments on SCVP
> 
> 
>      Alan,
> 
>      I frequently feel that you are too strongly committed to 
> the idea that DAP
> is superior to LDAP.  I would agree that at this point, 
> LDAP's main advantage is
> not that it's lighter weight as a protocol but that it runs over a
> lighter-weight and more widely distributed protocol stack - 
> maybe we should call
> it TDAP for TCP/IP DAP, and also that a TDSP would help 
> matters greatly (and I
> don't mean one with OSI layers 5 and 6 intact running over 
> port 102 either).
>      However, I do think you have a strong point here.  What 
> are the functional
> and trust differences between OCSP and SCVP, and what will keep SCVP
> significantly lighter-weight than OCSP once the requirements 
> types start in on
> it?  Ambarish, could you explain this to us or to the group 
> as a whole?  If
> there are no good answers to this, why should we have a clone 
> of OCSP when there
> is no networking technology advantage such as LDAP has over 
> DAP to carry the new
> one to success?
> 
>           Tom Gindin
> 
>

---

From: [email-masked]
Date: Fri, 27 Aug 1999 07:54:55 -0400

Hi Ambarish,

> have the client sending in a cert and getting back a yes/no

Why is the best answer to this need a protocol instead of a library? It
seems if this is a technical need, you could craft a nice library with
simple APIs to do this.
     Mez

---

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 27 Aug 1999 08:49:53 -0600

Nicely put, Mary Ellen, and a fair question.

It reminds me of some of the early SPKI justification, which put
a very high value on ease of implementation, as though Internet
protocols and applications were still being written by slave-labor 
grad students with few if any tools (such as ASN.1 compilers
or libraries).

Protocols are very expensive.  They take network resources,
where someone, at least, is effectively paying by the bit,
over and over again.  And protocols necessarily introduce
latency into the World Wide Wait-a-little-longer. And they burden
servers or other concentration points with computational demands
that are expensive and not easily met.

Libraries, on the other hand, are purchased, not rented, and after
depreciating the NRE are quite economical.  And because 
those libraries only have to service one human user, who can
only push the bottoms so fast, they really don't have to be all that
speedy. (I remember when I thought that 1200 baud was incredibly
fast, because I had difficulty keeping up with the incoming messages 
on the screen.)

So by and large, the CPU speed for such applications is irrelevant, 
and it is very difficult to imagine an application that couldn't verify 
a digital signature faster than it could send it off to a server to be
done for it. So all really talking about is the amount of memory that is
required, and it cost.

More than 30 years ago, one of my IBM-SRI instructors was preaching 
that despite the fact that IBM priced their machines as a percentage of 
component cost, and therefore adding more memory added a lot to the 
price of a computer, the development cost of trying to shoehorn applications
into too small memories was a lot more costly.

Now of course, people probably have more memory in a digital watch than
we used to have in mainframes back then, and a single chip contains 
1 to 4 megabytes or more, with very little discount for less memory.

So I'm still curious to learn exactly what kinds of applications really need 
these functions, and what the business justification is.

Bob

>>> <[email-masked]> 08/27/99 05:54AM >>>
Hi Ambarish,

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 27 Aug 1999 18:16:24 +0200 (MET DST)

I think that some of the SCVP discussion are like arguing
how to use a special version of a car, about your capablities
to drive, traffic jams, etc but your real intention is to find
an appropriate way to get somewhere.  

A user or even a client may not be interested per se in a
certificate chain or tree, the end application may need
a decision whether a given signature on a document is good
or whether a user is allowed to sign with its signature cert, 
or whether an encryption cert is good. These technical terms here
are in fact wrong, the user want to know who has signed a doc
and whether the signer was authorised, or to be sure that
he can exchange data in a confidential way with some partner etc.

> done for it. So all really talking about is the amount of memory that is
... 
> these functions, and what the business justification is.

The assumption is that the knowledge of how to validate a chain, the
cert chain, and the local company trusted root's and policies are
not available to the client. As soon as some online verification
is necessary, a one-shot proxy type doesn't seem such a bad idea.  

> seems if this is a technical need, you could craft a nice library with

I wonder whether someone remembers the discussion more than
a year ago about 'positive answers from OCSP'. There had
been several people who wanted a little bit more work to be
done by OCSP, especially the question of the availability 
of the signing CA cert. 

In fact, it is easy to slightly misuse OCSP and implement
whatever logic you want in the server. One could think about 
a kind of OCSP proxy or broker. 

OCSP provides an extension mecanism, thus the basic answer
of the OCSP would be the certificate chain, and in some
extension, the broker would return the actual responses
from other OCSP servers. 

In order to be syntactically conformant, a client can
always use a fake signing cert hash (or, in order to
be able to detect it, the cert of its broker.)

I gave up trying to ask extensions for OCSP shortly after
September last year after having read the DCS draft. 

Have fun.
Peter Sylvester

---

From: Ron Ramsay <[email-masked]>
Date: Mon, 30 Aug 1999 11:15:30 +1000

But a library will require that each client collect CRLs, that each
client be configured with the business/trust rules, etc. This sounds
like a significant systems administration problem.

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, August 27, 1999 9:55 PM
> To:	Ambarish Malpani
> Cc:	[email-masked]
> Subject:	RE: apologies and comments on SCVP
> 
> Hi Ambarish,
>

---

From: Carlisle Adams <[email-masked]>
Date: Mon, 30 Aug 1999 11:52:49 -0400

Hi Ron,

> ----------
> From: 	Ron Ramsay[SMTP:[email-masked]]
> Sent: 	Sunday, August 29, 1999 9:15 PM
> To: 	[email-masked]'; Ambarish Malpani
> Cc: 	[email-masked]
 
Not if the library does all this.  Then the only question is whether the
client acquires this functionality via a protocol or via a library with an
API (note that the library may achieve this essentially by itself or by a
protocol exchange with an SCVP server; this is invisible to the client).

Either mechanism (protocol or API) removes the complexity from the client,
so this is not the basis for the choice.  It may be argued that a library
requires a larger footprint than a protocol engine, but even this is not
necessarily true (since, as mentioned above, the library may perform the
validation by using a protocol to an external server), so this cannot be the
basis for the choice.

Ultimately, what it comes down to (it seems to me) is how many "things"
(applications, operating system, other protocol engines, etc.) on the client
platform need this functionality.  If the answer is "more than one", then
the library/API is probably a better architectural model than having each of
these "things" implement its own protocol engine for validation.  A single
library called by all these "things" is likely to be a smaller footprint
overall than multiple instances of a validation protocol.  If, on the other
hand, the answer is "one" (i.e., a totally dedicated, single-use device)
then it probably makes little difference, although the straight protocol
would have a slightly smaller code size than the protocol with an API
wrapper and might be preferable...

Carlisle.