This paper was presented at the 1997 CAUSE annual conference and is
part of the conference proceedings, "The Information Profession and
the Information Professional," published online by CAUSE. The paper
content is the intellectual property of the author. Permission to
print out copies of this paper is granted provided that the copies
are not made or distributed for commercial advantage and the source
is acknowledged. To copy or disseminate otherwise, or to republish
in any form, print or electronic, requires written permission from
the author and CAUSE. For further information, contact CAUSE at
303-449-4430 or send e-mail to [email protected].
Securing IT Resources with Digital Certificates and LDAP
and Lindsay Winsor
University of Colorado System Office
Electronic Information Security History
The age of information, commencing somewhere in the late 20th
century, is also the age of information assets. Tangible assets are protected
by lock and key or physical barrier but these material constraints aren't
effective for electronic information assets. We were able to secure information
assets fairly well when they could be corralled on mainframe computers.
But with the advent of networking, the task of providing authorized access
while preventing unauthorized access is exponentially more difficult.
Username and Password Security
A computer's equivalent of lock and key is the username and password. The
platform, its databases, and its applications may all maintain records
linking usernames to secret password information. This structure relies
on a pivotal assumption: if you know your user name, and some secret that
only you should know, then you must be who you say you are. There are three
standard ways to establish identity:
Username and password authentication uses only one factor: something you
know. In controlled environments of discrete computers, this might have
been auditor friendly. In the open era of the Internet it's a recipe for
Something you know (a password)
Something you have (a house-key)
Something you are (your fingerprint)
Networks developed without much thought to security. TCP/IP, the most prevalent
communication protocol, was designed around precepts of robust communication
rather than secure transactions. While the OSI network model designed a
layer between the application and network that could manage security handshakes,
TCP/IP left everything above the communication layer to the application.
Consequently each application developed its own negotiation strategy. Rather
than building a generic, reusable security mechanism, applications relied
on proprietary or embedded techniques for shuffling account information
across the network to the platform or application for validation.
As a result, on most Local Area Networks and Wide Area connections,
usernames and passwords are transmitted in clear text. Ethernets and TCP/IP
networks are analogous to telephone party lines. Eavesdropping, or "password
sniffing", is easily executed, usually undetected, by a variety of freeware
applications. Networks also permit any flaws in platform components to
be exploited for access. Sometimes errors are triggered intentionally in
routines designed to accept inbound email, telnet, or other "services"
to gain unauthorized access to systems. Sometimes legitimate services can
be used to exploit the course granularity of file level protections to
obtain encrypted password files. Once captured, automated dictionary attacks
typically decrypt about 50% of the passwords successfully. With a cracked
password the front door is open. Something only you knew is now something
a hacker knows and uses to fulfill the authentication requirements.
Tactical fixes to this widespread problem were developed: hubs that
scrambled packets preventing eavesdropping, one-time and encrypted passwords,
tokens, tickets, firewalls. Each of these new technologies mitigate risks,
but the strategic problem is something bigger.
Internet Commerce Requires a Solution
For the Internet to thrive as a collaborative environment and commercial
marketplace, a reliable method of establishing identity is required. Internet
markets are beginning to take shape with 1.2 billion dollars in online
commerce done in 1996, doubling 1995's revenue which in turn doubled 1994's
take. Analysts identify customer and vendor authentication and secure transactions
as the keys to procuring consumer trust and tapping into the exponential
growth of Internet use. As the Web browser strives to become the shopping
basket of online commerce, a great deal of commercial mindshare has been
directed to this problem.
To be successful, secure Internet commerce must be scaleable and easily
deployed (we're talking consumers). It cannot require monolithic account
structures or complex multi-cell domains. It must be simple, something
not based on a circle of friends but upon trust between strangers. Digital
certificates, based on public key encryption, seem to be a perfect fit.
Public Key Basics
It's said that encryption has two eras: before public key and after. Public
key was a clever technique patented by Diffie-Helman in 1974 (the patent
recently expired) and refined into an architecture by Rivest, Shamir and
Adelman (RSA). It was designed to securely exchange information between
complete strangers. Here's how it works:
A user generates a key pair, one public, one private. These keys are related
mathematically such that anything encrypted by one can be decrypted by
the other. Which you decide to make public and which private is purely
The public key is put out in some public place: a directory, a Web page,
in your email signature, etc. The private key remains on your desktop in
a password protected file.
When someone wants to send you a secret message, they use your public key
to encrypt a message with a public key algorithm.
Once the message is encrypted it can be sent to you via email, a network
protocol, or put in a public place.
You retrieve the message and decrypt it with your private key after unlocking
the key with the local password. Since the password never leaves your desktop,
it can't be exposed on the network. This is an example of two factor security,
something you know (the password to unlock your private key) and something
you have (the private key on your machine or cryptocard).
If you used your private key to encrypt a message, anyone could decrypt
it using your public key. What good is that? Well, it proves you are the
one that encrypted it and it hasn't been altered since you did so. This
forms the basis of the digital signature. Digital signatures can be used
to sign electronic documents, ensure their integrity (by encrypting a hash
or checksum), certify application code and components, setup secure topologies
on top of public networks, and encrypt data.
Before public key, a single key was used to encrypt secret messages. This
was called a symmetric key. Symmetric keys had to be in both parties hands
before messages could be exchanged. The biggest problem was how to get
the symmetric key to the other party securely. This was the problem public
key solved so elegantly: a way to get a secret key to someone without falling
into the recursion of them needing a secret key to have a secure enough
channel to get a secret key ... etc. (This is why Escher is popular with
people who've been in this business long.)
Session Encryption with Symmetric and Public/Private Keys
While the public/private keys could be used to encrypt sessions, in practice
they require significantly more computational overhead than a symmetric
key. Instead the public key of one party (say a web server) is used by
another party (say a web browser) to encrypt a symmetrical key for the
session. The encrypted symmetric key is sent back to the server, which
uses its private key to decrypt it. Now, both intended parties have the
symmetric key and no one else can get it. The public/private keys are just
used in the initial handshake to establish a unique session key.
By itself, public key technology doesn't provide authentication. Just because
someone creates a public key and makes it available as the key for "Jane
Doe" doesn't necessarily mean this is Jane Doe's key. How do you make sure
that a given key is reliability associated with an individual identity?
This is the function of a certificate. A certificate is a public key that
has been digitally signed by a recognized authority attesting that the
owner of the key is who they say they are. The process that does this for
a living is called a Certificate Authority or CA. So here's the bootstrapping
problem again. A CA signs a user's public key with its own private key
(see digital signatures to recap how this works.) But how can you trust
that the CA's public key really belongs to the CA? One way is by fiat.
Microsoft and Netscape browsers both come with a number of CA's pre-accepted.
Any certificate the browser encounters signed by these CAs is assumed to
be valid. Of course, if you are operating your own CA, you're not likely
to be on the "in" list. This adds a few more wrinkles. The client's browser
needs to accept your CA first, before it can accept any certificates you
might have signed for your organization. The process is relatively painless,
dialog wizards walk a user through the process of dynamically accepting
and installing a new CA, but it is definitely far from seamless.
A Place for Everything: LDAP
Public directories are essential in managing certificates. We need a place
to make certified public keys available and to record when they are no
longer valid. LDAP 3.0 is proving to be an effective repository for that
information. LDAP (Lightweight Directory Access Protocol)
has several characteristics that make it especially attractive.
Certificates and LDAP take authentication out of the application and off
the platform and put it on the network. LDAP can help do the same for authorization.
Authorization information is presently maintained in many locations for
each user. Email accounts, databases, file server accounts, calendaring
systems, web applications, other applications all store access information.
Tracking down that information when it needs to be updated can be difficult,
error prone, and time consuming. Products have been designed to artificially
glue all the known authorization files together under a single-signon veneer,
but the real fix is to treat authorization as a network service available
to all applications, databases, and servers. LDAPs' fluent access capabilities
make it a prime candidate for providing this security service as well.
It provides a light-weight set of APIs for accessing LDAP information across
the network through Java, C, C++, or Perl. It also provides components
for obtaining this information in higher level development tools such as
Visual Basic, Delphi, PowerBuilder, and others;
It provides synchronization between directories, replication for fault
tolerance and redundancy, and referrals for navigating through distributed
LDAP name spaces;
It provides efficient searches;
It allows authentication to the directory itself using public key;
It authorizes access to very granular levels, making it possible to permit
users to update specific attributes of their own data, administrators to
update authorization for users of their specific departments, all without
giving away the farm as is the norm in most application authorization interfaces;
And finally, besides being an exemplary directory architecture in its own
right, other components of certificate technology (web servers, web browsers,
certificate servers) are integrating LDAP as the first choice repository
for certificates, for certificate revocation lists, and other record keeping
attendant to managing a distributed infrastructure of public keys and certificates.
Public Key Infrastructure
Managing certificates is performed through an architecture called the Public
Key Infrastructure, or PKI. PKI is made up of technology, standards, and
policy. Policy is a species of documentation that plays an important structure
role in the planning and implementation of a PKI. It defines what standards
and technology will be used, and how the technology will be managed. As
technology, and standards change, so the PKI and its organizing policy
will need to change.
The Certificate Authority process operates on certificate server software.
It needs to communicate with one or more LDAP repositories. The certificates
are used by certificate aware web servers and web browsers. They can also
be used in certificate aware email and applications. Few applications,
beyond the Web browser, are currently certificate aware. But notable exceptions
are emerging: Oracle8 enables certificate
based authentication to its broad client/server base and several products,
including Peoplesoft, will be able to use certificates through the GSS-API
with Tuxedo. Most of us operate in heterogeneous environments with servers
and browsers from a variety of vendors. So understanding key PKI standards
helps in mapping integration of components into a certificates support
The figure below maps the major standards
that glue together components of a PKI. Most of them deal with ways information
about certificates is encoded and shuttled around. These links are important
when you start considering plug-and-play services for your PKI and may
help alert you to products that may have a proprietary hook in a key pinion
of the architecture. There are other standards that define the make up
of certificates themselves, negotiation of algorithms during various handshakes,
etc. They do not appear in the diagram.
PKI policy exists within the general security policy environment of an
organization. Digital certificates need a well established environment
of good general security policy and procedure before they can be effective.
The start of a PKI project is an excellent time to review your organization's
overall policy and procedure framework. Are your policies up to date, comprehensive,
well communicated? Are your security staff knowledgeable about the security
policies and in the habit of consulting and maintaining their procedure
documentation? Have you informed users of their security responsibilities?
A culture that understands the role of policy in security will have an
easier time implementing a PKI and digital certificates.
Policy Defines the Level of Assurance Provided
Digital certificates can provide a variety of levels of assurance of
the authenticity of the electronic identities of people, resources and
communications, depending on the policies that guide their creation and
use. A policy that requires minimal verification of a person's identity
before a certificate can be issued provides a much lower level of assurance
than one that requires independent verification of identity by a third
party. A policy requiring the issuance of revocation lists daily provides
more assurance than one that only requires weekly revocation. For some
purposes, relatively low levels of assurance are sufficient and the costs
associated with higher assurance can be avoided. High risk systems and
data need a high level of authentication. Each policy needs to be tailored
to the purpose for which the certificates will be used. An institution
may issue certificates conforming to several different policies, some of
which may be developed by other organizations
Procedures Implement Policies
While policies state what is to be done, procedures state how it will
be done in a particular implementation. Each Certificate Authority needs
a Certification Practices Statement (CPS) that may include different procedures
to be followed to provide different levels of assurance for different purposes.
The CPS defines the personnel and technical configurations and the processes
that will be used to accomplish each of the requirements of a policy. It
is useful to use exactly the same outline for a CPS as was used for the
policy it implements to assure that every point of policy is addressed.
However, when a single CPS relates to multiple policies, that may not be
Policy Chains, Policy Webs
CAs can be stand alone or they can relate to other CAs through chains
or webs. Stand-alone CAs "self sign" their own certificate and can operate
under policies and procedures they establish for themselves. In these cases,
the policy and procedure information can be combined into a single document.
If your CA's certificate is signed by another CA, it is part of a CA
chain or hierarchy. The administrator of the CA that signs your certificate
may want to review your practice statement to be assured that your procedures
are adequate to protect your CA and to create necessary audit records.
The signing CA administrator may also check that your CPS is adequate to
implement a specific policy. At the other extreme, the signing CA administrator
may review none of your documents, simply contracting with you to create
your CA certificate with no policy or procedure review.
Two CAs who are members of separate hierarchies may issue certificates
against essentially equivalent policies. If a single user needed to access
multiple resources, some of which recognize one CA and some recognizing
the other, it could be helpful to the user for the CAs to establish a trust
relationship. The Policy Mapping
Extension field defined in the X.509 v3 certificate standard is intended
to hold trust information, but servers and browsers (let alone applications!)
aren't able to use those fields yet. At present, each relying resource
(server or browser) must be instructed to accept certificates from either
CA. If applications develop the capability to use this field, CAs could
be directly connected into a web of trust without having to instruct all
resources about all CAs.
Policies and Procedures Inform Certificate Users
Relying parties, things like web servers or browsers that accept certificates
for authentication, need to review policies to understand what level of
assurance the certificate provides. Certificates issued under one policy
may meet the needs of the relying party while those issued under another
policy may not.
Subscribers, entities such as web servers or people that have been issued
certificates, need to be informed about policies and procedures because
they include requirements subscribers must meet such as how to protect
their certificate unlocking password.
The specification for X.509 v3 certificates defines Certificate
Policy Extensions to record and communicate policy and procedure information.
However, since applications and web browsers currently have limited capability
to using policy extensions, organizations that operate CAs also use other
mechanisms to disseminate information about their policies and procedures.
Subscribers can be informed by adding the URL for the applicable policy
and/or CPS to the certificate request form or instructions. Relying parties
can be shown the URL when the certificate is displayed.
What Needs to be Addressed in Policy and Procedure?
At this time, there is no standard for what must be addressed in a Certificate
Policy or a CPS. Various PKI service providers have developed recommended
frameworks for policies and procedures. The PKI Working Group of the IETF
issued an Internet-Draft containing a proposed
framework for Certificate Policies and Certification Practice Statements
on July 3, 1997. Even if adopted, the framework would become an informational
RFC, i.e., its use will be optional. So it is likely that various PKI
vendors will support different approaches to policies and procedures. A
vendor's approach should be one of the factors considered in selecting
In preparing to develop our own CPS, we reviewed all of the policy and
we could find. We then developed our own format that addresses the topics
that seem important to us in the sequence we think would make the most
sense to our users. As we learn more about the technology, as we expand
into new uses for certificates, as we seek cross certification with other
CAs, we expect the policy to evolve significantly. Some of the policy topics
that presented particular challenges to us are discussed below.
Legal responsibilities and limitations for CAs, subscribers, and
We began early to address legal issues, but quickly found ourselves
in need of professional advice. We have sent a query to University legal
counsel seeking help in identifying warranties, limitations on warranties,
disclaimers, loss limitations, and other policy statements that will inform
users about the certificates we issue, and that will appropriately limit
University liability in the event of a breach of certificate based security.
Certificate lifecycle issues:
Verifying subscriber identity;
In the mainframe world, we weren't embarrassed (but probably should
have been) to require users to submit multiple signatures on paper to request
authentication and to attest to their identity. In the networked computing
world, that seems like an antiquated procedure. Yet we face exactly the
same problem: how do we determine that the person or resource requesting
authentication is who they say they are? Resources (such as web servers)
are easier to verify through checking domain name servers or other technical
sources. An institution may designate "registration authorities" to do
"in person" verification of individuals for systems that require high levels
of authentication assurance.
The longer the life of the certificate, the less often the user has
to seek, install, and use a new certificate (which is good), and the more
opportunity there is for the certificate to be compromised (which is bad).
In setting the lifetime for certificates, policy makers must assess the
risk associated with the data and processes that will be accessed via those
certificates. Higher levels of required authentication assurance must be
supported with shorter duration of certificate life. Eventually, all certificates
expire and policy must also address the requirements for renewal. It would
be nice to be able to use an unexpired certificate to verify a request
for a new certificate if first time verification requirements are onerous,
but we don't know how to do that yet.
Certificates need to be revoked when the private portion of the certified
key pair has been compromised or when the user no longer meets the requirements
that were critical to issuance. Retired web servers should have their certificates
revoked just as promptly as retired staff members. Policy needs to define
the conditions under which certificates are revoked and the process for
notifying everyone who might care.
Communication of certificate, policy, and procedure information;
Our policy and procedure information will be published on our web site.
We will require certificate applicants to attest that they have read the
CPS summary and will seek to make highlights of the CPS available to web
browsers when they attempt to communicate with a certified server.
Technical security for the CA;
The certificate server and its CA software become a major point of risk
in a PKI. Stringently limiting access to the CA through minimizing network
connections, software firewalls, and carefully maintained access privileges
Procedural and staffing security for the CA;
Our policy addresses backup procedures and schedules, and recovery processes,
all of which will be tested before we begin to issue certificates. We've
defined separation of duties and determined how to implement them with
part-time assignments to multiple staff.
Termination of the CA;
What should happen if our CA were to go out of business? What amount
of notification should be given to subscribers and relying parties? How
will the records archives be maintained? Our CPS
is attempting to plan for this occurrence.
Policy and procedure maintenance;
Changing the policy or procedure could change the level of assurance
provided by certificates issued under the policy and could affect the willingness
of some resources to accept the certificates. A process for notifying concerned
parties of proposed changes, for receiving and processing comments, and
for approving and publishing final changes is specified in our CPS.
There is at least one significant institutional political issue that addresses
the role digital certificates will play in an institution's enterprise
security architecture. There are several competing technologies, including
PKI, that could be an enterprise solution by themselves. Will an institution
choose a single technical solution or will it decide to integrate two or
three technologies, using each where they provide the best answer? PKI
and Kerberos are leading contenders in higher education. While Kerberos
is more proven and widely implemented in higher education, it isn't a good
solution for Internet commerce. Several institutions have statements
of direction or actual implementations that recognize a role for both
mechanisms or a commitment to study how they should each be used. Technology
may also assist in supporting both. An enhancement to Kerberos, since release
5, introduced public keys as native
components of its architecture. Microsoft's NT 5.0 also has the ability
to map Kerberos tickets to digital certificates allowing users to seamlessly
participate in overlapping security models.
Besides local politics, it will be important, even for academia, to
pay attention to legislation that may affect a PKI's operational requirements.
Federal legislation related to key-escrow is targeted to those managing
PK directories and issuing certificates. State legislation on digital signatures
targets the type of assertions PKI policies make about using identities
to approve transactions for goods and services. Both may affect a University's
strategy, particularly in their interfaces to commercial services and extranets.
We also face a market issue in that PKI is to some extent a captive
of the browser wars. To date, the major contenders seem to be supporting
most certificate standards. However, that doesn't ensure complete interoperability.
Other issues that are part and parcel of deploying digital certificates
This is a partial list! Threaded throughout this list are issues of technology,
standards, policy, and politics that must all be resolved in some phase
of the PKI implementation.
How certificates are requested, approved, delivered, and installed in a
range of products like Netscape Navigator, Internet Explorer; SSL capable
Web browsers such as Netscape, IIS, Stronghold, etc.;
How certificates are revoked, renewed, expired;
How certificates map to authorizations on platforms that have not
yet "outsourced" their authorization information to a directory service
How access to authorization information is controlled for services that
have "outsourced" this information;
What type of user information schemas are used in the authorization and
How to establish, accept, and deploy Certificate Authority information
How to create and use different levels of certification, for instance,
providing a high level of authentication for Web servers that take credit
cards versus a different level of trust for those that report grades.
PKI is past the early adopter stage, but is still cutting edge. Large scale
implementations exist, like the Government of Canada's Public Key Infrastructure,
but most of the large implementations have been done with proprietary PKI
suites, like Entrust. A number of vendors are selling the pieces to construct
this suite yourself. Netscape provides certificate servers for issuing
your own Digital IDs for clients, servers, S/MIME, object signing, etc.
and they provide some level of integration with LDAP. Microsoft has a public
key framework built into NT 5.0 using certificates and LDAP directory services.
A number of standards have been defined and unevenly adopted by products
governing how IDs move between pieces of this architecture, but there are
rough spots. Developing your own PKI at this point takes a degree of faith
that, due to the commercial momentum, these pieces will play together.
The ability of applications and databases to work with network based
authentication and authorization services is still in early stages of development.
Netscape, Microsoft NT 5.0, Lotus and other vendors are using LDAP stored
authorization information. Some transaction monitoring systems such as
Tuxedo are in early stages of providing this capability. But more development
is needed before many client/server and legacy applications will be able
to take advantage of external security services.
We have chosen a narrowly defined purpose for our first venture into certificate
territory. We intend to issue certificates to web servers so that they
can authenticate themselves to browsers and so communication between the
server and browsers can be encrypted. Our primary reason for securing these
communications is to protect student admission, registration, and payment
data, but we expect it will serve other purposes as well.
We are using Netscape's certificate server and LDAP to create our PKI,
although we expect to include servers and browsers from a variety of vendors,
among them Netscape, Microsoft, and Stronghold. We will sign our own CA
certificate which means that both servers and browsers will need to accept
and install the CA certificate and the server certificate. This will require
that we carefully develop user information materials to help browser users
understand who is operating the CA and why it can be trusted.
We began developing our policy and Certification Practice Statement
early in the project and found that helped us identify technical concerns
as well. We are keeping our policy and our technology as simple as possible
at this stage to increase our chances for success. Later, we may change
both the technology and the policy as we undertake to meet new needs, as
the technology and theory mature, and as we learn more about certificates,
LDAP, and PKI.
Where is this leading?
As workflow and groupware emerge into the mainstream, we can take advantage
of certificates that have been used to authenticate client sessions to
provide also for non-reputable signatures. As we begin taking advantage
of distributed processes, we can reuse the same mechanism for authenticating
executable content. Middleware services like transaction processing, CORBA,
and messaging provide standard security exits in the form of the GSS-API
which now has commercial support for certificate based authentication.
At the same time we are encouraged by the directions of Java's JDK which
incorporates X.509 into the fabric of the standard Java distribution, Microsoft's
CryptoAPI and use of X.509 and LDAP in NT 5.0. SET initiatives are finally
taking off, DNSafe is poised to address critical issues around reliable
use of Domain Names as part of network authentication. Finally, CryptoCards
and readers are beginning to be incorporated into standard keyboards and
PC peripherals. There is significant momentum that is rapidly completing,
enhancing, and extending both the technology and the theory of PKI.
Luckily, you don't have to tackle all this at once. A PKI can, and probably
should, be implemented incrementally. The "Geoffrey Moore Chasm" (Crossing
the Chasm, HarperBusiness, 1991) advises that you navigate gaps from early
adopter to market majority with bridging techniques particular to the stage
of adoption the technology has reached. By working with components of PKI
and adhering to standards for interoperability, you should be able to navigate
these gaps strategically. PKI's promise as a universal fabric to authenticate
users and LDAP's ability to centralize authentication and authorization
information can be realized in practical steps that return immediate gains.
Unification of standards around new technology, as is occurring with LDAP
for directory services for example, requires the new technology to be adaptable
enough to encompass and typically extend the more proprietary or limited
technology it replaces. In the age of collaboration, it also must serve
a global, rather than localized market, and it must be propelled by both
mind and market share. All the indicators point to PKI as meeting these
requirements and digital certificates becoming the passport for secure
transactions across a broad spectrum of services.
Certificate and CRL Profile Internet-draft has a complete discussion
of policy extension fields. Note that this is a work in progress
and may change at any time.
One vendor's view of policy and procedure requirements is contained
in a white paper from Entrust Technologies titled "Certificate
Policies and Certification Practices Statements" by Sharon Boeyen, dated
Policy and Certification Practices Framework Internet-draft provides
an explanation of subjects that might be addressed in policies and CPSs,
as well as a possible structure for those documents. Note that this
is a work in progress and may change at any time.
policy statement for the Government of Canada Public Key Infrastructure
follows the framework proposed in the IETF Internet-draft. It is
very helpful to see the framework fleshed out.
for Verisign is a live, working practices statement.
CPS draft is in preliminary stages of development! It still acknowledges
what we don't know as much as specifying what we think we know. We
are trying to design a document that is as readable as possible.
Other institutions who are addressing
the interaction of PKI and Kerberos include MIT,
of California (Office of the President), and the University
The main page for PKCS, or Public-Key
Cryptography Standards developed by RSA Laboratory information can
be found at:
Individual PKCS Standards Referenced
supported for Certificate Download in Netscape
Standards (including X.501 and X.509 --- pay per view)
Guide to a Subset of ASN.1, BER, and DER
Layer Security. IETF draft for standardizing SSL 3.0.
RFCs for Multipurpose Internet Mail Extensions
Security. Oracle's new security capabilities and use of certificates
Security Service Application Program Interface, Version 2. GSSAPI is
a generic framework for establishing authentication. GSSAPI exits are supported
in TP Monitors and other products to accommodate any security solution
that conforms to the API. Both Kerberos and PKI have GSSAPI modules.
API. A framework for Java based applications to use cryptographic functions,
including public key and certificate interfaces. The Java
Naming and Directory Interface provides analogous APIs to LDAP.
Crypto API. Microsoft's
32 bit API and CSP Developer's kit (which contains the DLLs which actually
implements the cryptographic algorithms.)
BCERT, an X.509 toolkit
a cryptographic toolkit from RSA with hooks to Microsoft's Crypto API.
They also provide JSAFE
for application SSL in Java, and S/MAIL
and S/MIME toolkit.
SSLAVA. A Java SSL API
implementation in C source code for non-commercial use from Netscape.
SSLeay. Eric Young's
([email protected]) implementation of SSL and supporting libraries.
#6: Extended-Certificate Syntax Standard
#9: Selected Attribute Types