RE: SCVP-01

[Paul Hoffman / VPNC <paul.hoffman@xxxxxxxx>]

At 12:12 PM 8/30/1999 -0400, Carlisle Adams wrote:
> Not exactly what we were all looking for (i.e., "concrete details regarding
> who does need this").  I understand that you may not be at liberty to share
> any specific names, but even some generalities might help.
Oh, good, that's the easy part. :-)

>   For example,
> what you've said above ("people who want to use public key cryptography
> without the overhead of understanding all of PKIX") suggests that for the
> people you've spoken with this is an understanding or complexity issue,
> rather than a footprint issue.  Is that true, or is it both, or are there
> other motivators as well?
I'll speak for my interest in helping to start the SCVP work wearing my 
VPNC hat. In speaking to VPN vendors, I heard two things that bothered me:

- some still don't handle certs at all because PKIX is too difficult

- of those that do handle certs, some do it very poorly (this can be easily 
shown in the interop testing in the VPN world)

Both groups want an easier way to handle certs. Clearly, anyone who can 
write an IPsec implementation can probably also write a PKIX 
implementation, but they don't want to waste the resources to learn the 
intricacies of path validation (and the well-known divergences from 2459 in 
the real world) and to write code for it. Thus, to use your phrase, it is 
both an understanding and complexity issue.

> I initially had the impression that the driver was very constrained devices;
It could be for that as well, but that is by no means its only target 
market. We've been saying that over and over, and thought we had made that 
clearer in the -01 draft than in the -00 draft.

> now I'm wondering if a more accurate picture is that the devices are
> sufficiently powerful but those doing implementations don't really want to
> understand all of PKIX.
"want to" or need to. And, there is still the two other main areas where 
SCVP could be useful:

- An organization that wants to centralize validation policy can require 
that all clients use SVCP and a particular server, and then put the policy 
on that one server. The only other option for such an organization is to 
only use clients that have configurable policy in the clients' validation 
stack; you can easily guess how few clients meet that criteria.

- To aid clients in collecting validation information. The concept of "just 
use LDAP to get the certs in the chain" assumes both that this will work, 
and that using successive LDAP queries is efficient for long chains. 
Neither assumption may be true. A single call to a server that spends its 
time looking to fill in interesting chains and making sure that the certs 
that it caches are up-to-date, well-formed, and (by the way) not revoked 
seems like a better way to do things even for very able clients.

> You're right; no argument here.  However, this does not necessarily make
> SCVP the right answer, since (as Mary-Ellen has pointed out) a
> sufficiently-powerful library with a sufficiently-simple API brings the same
> benefit.
I agree. If we believe that such a library will be generally available, 
correct, and configurable, then an external protocol won't be needed. I'm 
not sure we can assume that (or, to be fair, that the work we put into 
making the protocol will be worth the effort if such libraries proliferate).

--Paul Hoffman, Director
--VPN Consortium