Existing PKI implementations began with specifying their
certificate formats and the name spaces through a
pre-defined hierarchies, such as the DNS(Domain Name System) name hierarchy.
This method entails inflexible implementation.
The properties of an agent make it ideal for the application of PKI.
Since agents can adapt to the
environment, instead of specifying the format of
certificates, name space or hierarchy structure, we allow user
to specify the details for implementation.
Typically there are multi-parties involved in a security protocol, they
have to cooperate with each other to make the protocol work. If the parties
involved in the protocol are delegated by agents, then they can naturally
cooperate with each other according the the security policy. And since
agents are highly autonomous, human beings don't need to get involved into
the details of the protocol.
Thus, we can develop a security agent to deal with the
authentication service.
This provides a flexible framework where different applications can
specify their own certificate formats.
From the viewpoint of a user, the security agent can be thought
as a kind of configurable facilitator that can be employed by
any group of users, organization, community etc. to construct
their own authentication verification service system.
``configurable facilitator'' means that we do not pre-specify
any particular certification format and hierarchical relationship
in the software (like in other traditional PKI projects), but
allow the users to define the format(s) of the certification(s)
and the name space(s) as they need (customized).
The hierarchical relationship is dynamically formed as the
agents apply/issue their certificates according to the
goals of the applications. Of course, the certificate formats in
existing PKI implementations can be adopted if they are suitable
for an application.
From the viewpoint of PKI structure, a security agent can be
thought of as a node in a dynamically formed hierarchy. More
than one authentication verification systems may cross a node,
since a single security agent can hold multiple certificates with
different certificate name (such as ``PGP certificate'', ``RSA
PKCS certificate'', ``X community certificate'', etc.), formats and
hierarchical relationships for name space. (refer to Figure 2.1).
Security agents, like other application agents, communicate
with each other with KQML. However, the current version of
KQML does not support many security operations needed in
public key management, although some changes were made for
agent security in [11]. We propose a security extension of
KQML in the following section,
our extension enable agents to
identify multiple certificates and cooperatively conduct
security interoperations.