22.12.2012 Views

Front cover - IBM Redbooks

Front cover - IBM Redbooks

Front cover - IBM Redbooks

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

6.1.3 Notes IDs<br />

Users and servers in the organization have fully distinguished names based on<br />

their certifiers. Each layer in the certification hierarchy inherits the fully<br />

distinguished name of the certifier used to create it, and is in turn an ancestor to<br />

the layers below it.<br />

In this example, the organization level certifier Acme has the fully distinguished<br />

name "o=Acme". The organizational unit certifier Switzerland has the fully<br />

distinguished name “ou=Switzerland/o=ACME”. The organizational unit certifier<br />

USA has the fully distinguished name “ou=USA/o=ACME” and the organizational<br />

unit certifier East has "ou=East/ou=USA/o=ACME"<br />

For Sandy, her fully distinguished name is “cn=Sandy/ou=Switzerland/o=Acme”.<br />

For Dave, his fully distinguished name is “cn=Dave/ou=East/ou=USA/o=Acme”.<br />

When registering a server, the same applies, with the only difference being that a<br />

server ID is created instead of a user ID.<br />

With regard to authentication, users and servers may authenticate with each<br />

other if they have at least one common ancestral certificate. In our example, this<br />

means that all users in the organization can authenticate with each other<br />

because they have the Acme certifier in common. Entities that don't share at<br />

least one common ancestor can still authenticate by going through a<br />

cross-certification process, which is <strong>cover</strong>ed later in this section.<br />

Finally, hierarchical certification is definitively the way to go, and organizations<br />

that are still using flat certification should seriously consider converting to<br />

hierarchical certification (and thus hierarchical certifier, server, and user IDs), for<br />

the following reasons:<br />

► Increased security<br />

► Increased flexibility of access control<br />

► Easier and better organized Notes ID file generation and certification<br />

► Improved maintenance<br />

At the core of the Notes PKI is the Notes ID. The Notes ID is a small file<br />

(meaning it is only a few kilobytes in size), which contains many things that are<br />

necessary to use the services provided by the PKI built into the Notes client. We<br />

review these and <strong>cover</strong> the different types of Notes IDs in this section.<br />

Chapter 6. Public key infrastructures 191

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

Saved successfully!

Ooh no, something went wrong!