Subject: IPSec device requirements from PKI server (DCS/CSVP/OCSP)

From: Sara Bitan <[email-masked]>
Date: Thu, 15 Jul 1999 00:56:21 +0300

During the discussion in the morning session of the working group today,
people had refereed to the requirements of a PKI client from a
DCS/CSVP/OCSP server.

I would like to present my perspective as an IPSec vendor, both from the
security gateway and the IPSec client point of view.

I would like to verify the certificate within my IPsec implementation.
One requirement I have from PKI server is to be able to produce a
certificate chain from a given certificate to a trusted CA(s) I specify.

There are several reasons to this approach
1) I don't like the IPSec device to perform the trust path search and be
able to support LDAP, HTTP or other retrieval protocols for this
purpose. No trust is needed for the delegation of the search, assuming
the certificates in the chain and the CRLs are to be trusted.
2) why not delegate the certificate verification to a PKI server?  I
wouldn't trust anybody to verify the signature for me. An IPSec device
has the public key technology (required for IKE), hence, it has the
ability to verify the signature on the certificate.
3) a certificate verification server will not be aware of the list of
CAs that the IPSec device doesn't trust. I wouldn't like to configure
the certificate verification server with the list of trusted CAs for
each security gateway and IPSec client.
4) efficiency reasons - if the IPSec device gets the certificate chain,
it will be able to cache it and to use it (or parts of it) whenever it
needs.  It will be able to save some of the queries to the PKI server.

Since I want the IPSec device to verify the certificate chain, I would
also like the PKI server to be able to separate the revocation status
from the trust path search. This way the IPSec device will be able to
cache the certificate chain and just check the revocation status.

Regarding the certificate chain there is one problem that was raised.
Suppose there are several chains leading from the peer's certificate to
the trusted CA. Suppose some are legal and some are not. Which
certificate chain should the PKI server return?

Once again, this is my private point of view of the requirements from
and IPSec vendor's perspective. Hope that's helpful,

 Thanks, Sara.

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 15 Jul 1999 09:56:00 -0400 (EDT)

> From: Sara Bitan <[email-masked]>
> 

This sounds like a reasonable approach.  Given item 4 (the IPsec device
is capable of building a full chain from cached partial chains), there
doesn't appear to be a problem.  If the PKI server forms several valid
chains rather than stopping when the first is found, it could return
the union of the certs contained in all the chains and the device could
construct whichever path it wanted from among the pile of certs in the
cache.

If the device doesn't trust the PKI server (item 2), then it must
validate the chain itself.  Therefore, except for cache overflows, it
doesn't matter in principle whether the PKI server returns all certs in
all chains, all certs in all valid chains, or just the certs in the
first valid chain it finds.   In practice, since the PKI server must
attempt to send at least one valid chain to the device in a finite
amount of time, it may wish to do some chain validation checks in order
to prune the search space.