If you’re deploying a public-key infrastructure (PKI) and expect your mission-critical applications, such as virtual private networks (VPN), to connect instantly, think again. Lack of a clear focus for PKI, coupled with a lack of interoperability across all PKI-using systems, will cause untold delays in getting products to work together.
A few weeks ago, I conducted an informal survey at a VPN interoperability bakeoff in San Diego. The purpose of the survey was to let certificate authority vendors know what VPN vendors are implementing and to let VPN vendors know what the others are doing so they can reach agreement on how to proceed with certificate authentication in IP Security. The results were depressing.
There was no general agreement on enrolment, the mechanism by which a VPN gets its own certificate, usually when you install the system. About 80 per cent of the vendors surveyed support manual or Web-based enrolment using a fairly standard request format; unfortunately, they were almost evenly split regarding the format for the response they expect from the certificate authority. In a stunning rebuke of the standards process, only a handful of vendors used the IETF’s Certificate Management Protocol (CMP) standard. The fledgling Simple Certificate Enrolment Protocol, which was cobbled together outside the IETF and made public only last month, had more users, despite its obvious technical problems.
The good news is a solid majority of VPNs check the revocation status of the certificates they receive. This is particularly important for VPNs used in extranets and in corporate networks that assume if a user got in through a VPN, he should have wide access to resources on the net. The bad news is there was no agreement on how to find revocation information. No common methods (checking revocation information given with certificates; manual checking with Lightweight Directory Access Protocol or HTTP; checking at locations listed in a certificate) were supported by more than half the implementers. Even though all VPN systems are on-line, none of the implementers was using the IETF’s Online Certificate Status Protocol standard.
Perhaps the most depressing discovery was that almost one-third of the VPN vendors didn’t support chains of certificates: They required all incoming certificates to be signed directly by a trusted root. No one ever said that verifying a path of certificates from the one you are given to one you trust is easy, but it is pretty much a requirement if we expect PKI to scale beyond today’s small number of users.
The blame for this mess can’t be laid solely on VPN vendors. Certificate authority vendors have been slow to roll out support for CMP and have often pooh-poohed the need for good revocation checking. And the IETF has not made certificate path validation easy (the PKI X.509 Working Group is now considering a major clarification to the rules). The result is not pretty for the VPN industry and bodes poorly for other markets that rely on certificates, as well.
Hoffman is director of the VPN Consortium and the Internet Mail Consortium. He can be reached at [email protected].
