[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
???????????????
Paul I could easily spin each of your observations into something positive,
point out the places where you are wrong, and drag this into a 1000 post
thread. But instead I'll just ask, what were you thinking? I mean even if
you really believe the VPN-PKI world is askew is this the best way for a
consortium to encourage adoption of its technology? I know Entrust is not a
member, so I guess I missed the meeting where you explained how bad press
helps.
Not to mention bakeoff etiquette.
Now this has me mystified?
NETWORK WORLD FUSION FOCUS: PAUL HOFFMAN on
SECURITY
Today's Focus: Lack of agreement on PKI bodes ill for VPN users
02/08/00
Today's Focus: Lack of agreement on PKI bodes ill for VPN users
---------------------------------------------------------------
By Paul Hoffman, guest columnist
If you're deploying a public-key infrastructure and expect your
mission-critical applications, such as virtual private networks, 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 enrollment, the mechanism by which a
VPN gets its own certificate, usually when you install the system.
About 80% of the vendors surveyed support manual or Web-based
enrollment 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 Enrollment 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 online, 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.
About the author:
-------------------------
Paul Hoffman is director of the VPN Consortium and the Internet Mail
Consortium. He can be reached at paul.hoffman@vpnc.org.
Copyright Network World, Inc., 2000
Follow-Ups: