Bridging The Business-to-Business Authentication Gap
Microsoft, on the other hand, may have more developers already in hand, but it must also contend with security experts who argue that its API set is flawed. Robert Moskowitz, who oversees security for the Automotive Industry Action Group effort to build an IP network for automakers and their 20,000 partners and is a contributing editor of Network Computing, says the CryptoAPI has "some blatantly obvious holes." His own API preference is PF-Key, which was developed at the Naval Research Lab and is slated for incorporation into Sun Solaris. Sun won't say whether PF-Key is part of its new API framework, but Sun is among the authors of a recently introduced IETF PF-Key standards draft.
For multivendor users or developers in need of PKI-enabled applic
ations, the API scene isn't apt to become crystal clear anytime soon. Uncertainty will delay major rollouts, because without common APIs, it's up to corporate users to make s
ure each of their multivendor applications is security-aware. And even though browsers and Java apps are apt to be certificate-enabled, the real problem is that the bulk of applications are homegrown or legacy software.
What's the answer? Glenn Ricart, Novell's chief technology officer, wishes the IETF would take up the banner of reconciling API frameworks, even though the IETF's mantra has traditionally been one of API forbearance.
APIs: Too Much of Too Little
But although API unification is one of the bigger issues, other matters must also be resolved. Many developers say, for example, that the CryptoAPI and CDSA are both vague on issues like directory access and policies. In Microsoft's case, the omissions were intentional--Microsoft's new CA includes ActiveDirectory integration and Microsoft wants developers to use its
own ActiveDirectory interfaces; policies can be implemented via the service provider model in the CryptoAPI
(for more on Microsoft's CA)
.
Patrick Richard, Xcert Software's vice president of technology, says developers need tools and more detail than CDSA's 20,000-foot view can offer. Choices must be made regarding the distribution and access control of attribute and security information, he says.
Xcert has its own twist on APIs, though. It promotes an API called XUDA, which Richard believes "is an excellent candidate for implementing underneath CDSA." XUDA supports public and symmetric Secure Sockets Layer (SSL) transports, authentication and policy rules. Xcert is also working with a partner to develop a client-side proxy that can make any IP-based application or token (like a smartcard or Fisher's floppy drive authentication device) PKI-aware. Xcert expects to announce several XUDA partnerships this summer, including what we speculate may be an alignment with Entr
ust.
Can a small start-up, even one as innovative as Xcert, prevail against the API big guys? The Burton Group's Lewis doubts it, but he says he's impressed with the way Xcert uses its
API to draw on and provide interoperability for two seemingly opposing IETF CA-to-CA infrastructure camps--X.509 version 3-based PKIX and the less-mature SPKI/SDSI. The implementation also removes policy and authorization attributes, such as who can access a particular database after business hours, from the certificate and places them in a secure directory that's easier to administer. This simplifies changes and protects privacy by ensuring, for example, that the rest of the world doesn't see that a certificate holder has NATO clearance or access to a Web porn site. The API and implementation handle PKIX's distinguished names as an attribute that appears as an indexed number in a secure database. This means anonymous certificates can be created that delineate SDSI-like privilege attributes.
In SDSI Hot Water
W
hether standards-makers will come up with their own mergers of PKIX and SPKI/SDSI remains to be seen. And to further complicate the matter, important European vendors--Bull, ICL and Siemens Nixdorf--are shipping or have announced CAs based on yet another standard with its own infrastructure, SESAME. Still another approach, Pretty Good Privacy (PGP), often is dismissed as having too informal an infrastructure, though it can be implemented hierarchically.
The IETF segregated its two leading infrastructure efforts when it became clear that mixing PKIX and SPKI/SDSI supporters was akin to introducing two male betas in one fish tank. Many PKIX supporters claim SPKI/SDSI is an academic exercise, while SPKI/SDSI aficionados say dealing with ISO-based X.509 specs is like getting lost in Paris' sewer system--you must trace hard-to-obtain documents and explanations that lead in a thousand directions.
|
REPORTS
ANALYTICS
Follow 
