22.12.2012 Views

Front cover - IBM Redbooks

Front cover - IBM Redbooks

Front cover - IBM Redbooks

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

6.1.2 Certification hierarchies<br />

When Lotus was first introduced, it offered only one type of certification: Flat<br />

certification. Hierarchical certification was introduced with Release 3 of Notes.<br />

Both flat and hierarchical certification were supported, in that it was possible to<br />

generate flat and hierarchical certificates. With the advent of Release 5, it was no<br />

longer possible to perform flat certification; however, previously generated flat<br />

certificates are supported in versions 5 and 6 for backwards compatibility.<br />

Flat certificates<br />

Flat certificates are a remnant of the way things were done in the early days of<br />

Lotus Notes and the fact that they are still supported in version 6 shows the<br />

commitment by Lotus in regard to backwards compatibility. And, by discussing<br />

them here, we are demonstrating our commitment to addressing all aspects of<br />

security in this redbook. However, we will <strong>cover</strong> mainly differences and points of<br />

interest. Readers can consult previous documentation on Lotus Notes to<br />

acquaint themselves fully with flat certificates.<br />

The following are the key differences between flat certificates and hierarchical<br />

certificates.<br />

► Flat certificates generate IDs with flat names, which are stamped by one or<br />

more Notes certifier IDs. In contrast, hierarchical certificates create structured<br />

names, which include the name of the Notes certifier IDs, which are<br />

organized in a well-defined hierarchy.<br />

► Flat certificates are stored solely in the Notes ID file, whereas hierarchical<br />

certificates are also stored in the Public Address Book.<br />

► In regard to user authentication, with flat certificates, authentication is only<br />

performed in one direction, the server authenticating the user. A user can<br />

access any server with which they share a common certificate, provided that<br />

the certificate is trusted by the server.<br />

► In regard to server authentication, with flat certificates, authentication is<br />

performed in both directions, as both servers have to authenticate each other.<br />

If the organization’s server and an external server share one common<br />

certificate, they can only authenticate if both servers trust that certificate. This<br />

means that one of the servers has to trust a certificate that does not belong to<br />

their organization. If this is your organization, the result is that any other<br />

server that holds that external certificate can access your server. This is a<br />

huge security risk! It means that any users or servers the external<br />

organization has also given their certificate to can now access your<br />

organization’s server. This is therefore not a viable option if the goal is to<br />

restrict who can access your organization’s server. It is far more secure to<br />

have two certificates in common, one from each organization, and to only<br />

trust the certificate your organization owns.<br />

Chapter 6. Public key infrastructures 189

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!