How should I document my Public Key Infrastructure?

Question

I'm preparing to document a 3 tier PKI (with multiple second level policy CAs) and want to create a document that is useful, technical, and not too overwhelming to the non-PKI expert.

I suppose the audience could be broken up into the following roles

• People who request certificates
• Administrators who approve certificates
• Technical PKI administrators who replace me in the future

There could be more roles, but I don't want to create any unnecessary work for myself. No-one is asking for this information per-se, but I know this body of knowledge I've gathered needs to be stored somewhere.

Question

• What audiences should a PKI administrator generate documentation for?
• What technical facts should be in the respective documentation?
• What should be out of scope (too detailed, or too simple) in each document?

This type of question comes from 1998 thinking as an MCSE where Microsoft had template documentation and checklists for various aspects of Windows. If other vendors (Entrust, etc) have relevant sample documentation that would be useful to structure my thinking.

Answer 1

You at least need :

• documents to describe processes involved in certificates life cycles :

  *request for a new certificate

  *certificate revocation

  *certificate renewal

both for administrators and users (probably two different documents for each process)

• a general architecture document, describing CA levels and their purpose

That's in my opinion the bare minimum. Depending on who manages certificates and what their expertise level is, various tutorial documents with screenshots and so could be useful.

Answer 2

PKI-administrator is not really a well defined role, so the scope of his documentation is vague here.

As a Chief Information Security Officer I would ensure that the following documents exist:

• System Administration doc, for a technical audience - sysadmin who need to set up servers and clients (configuration, architecture, ...). Some interesting point would also fix what can and cannot be changed by sysadmin without having to raise security/legal concerns.
• User documentation - simple "follow the guide" document on what do if you want to do this (startup guide, day to day use, specific tasks like renewal or revocation)
• Legal/conformity documentation - a clear description on measures made up to ensure respect of obligations, or measures made to reduce a risk from the risks analysis. Short idea: document for auditors.

In your specific case, there could also be a specific document tailored for the Certification Authority leader (how to verify CSR and authenticate the person asking for certificate, how to sign a CSR etc) as well as a Certification Authority Policy document that state what you guarantee as a CA.