PKIX, certificate assurance classes, and identity federation

PKIX — five entities, six functions

A certificate on its own is a signed blob. The PKIX model names the machinery around it, and splits into two groups.

PKI users — one role: the end entity, the user, device or server the certificate is about.

PKI management entities — four roles:

• the certification authority (CA), which issues certificates and CRLs;
• the registration authority (RA), a subdivision of the CA's management functions that handles end-entity registration only — it vouches that an applicant is who they claim to be, and it issues nothing;
• the CRL issuer, to which a CA may delegate CRL publication;
• the certificate and CRL repository, where relying parties fetch them.

CAs also cross-certify one another, which is how two hierarchies come to accept each other's certificates without a common root.

Six management functions need protocols to carry them: registration · initialization of key material · certification · key pair recovery and update · revocation request · cross-certification. "RA registers, CA issues" is the pair to keep straight, because registration authority turns up as a distractor whenever a question is really about something else.

Assurance classes — the axis is how much verification happened

Before browsers showed a padlock and nothing else, a commercial CA sold certificates in graded classes, and the grade recorded how thoroughly the subject's identity had been checked. The scheme is historical — the source is named in the callout — but the exam asks for it, and the underlying idea is very much alive.

• Class 1 — confirmation of an e-mail address, and nothing more. For casual web browsing and personal e-mail.
• Class 2 — adds verification of the applicant's details against a third-party database. For individual e-mail, subscriptions and software validation.
• Class 3 — independent verification of the applicant's existence and identity, i.e. someone checked that the organisation is real. This is the class for e-banking, personal banking, e-commerce servers, software validation and membership-based online services.

The memory hook is the rising verification effort: e-mail only → database check → someone actually verified the organisation exists. And the scheme did not die, it was renamed: today's domain-validated / organisation-validated / extended-validation split is the same ladder, and you can inspect which rung a real site is on from your browser right now.

Identity management, and then federation

Identity management is the discipline of running one automated, central scheme through which everyone an organisation authorises — staff, contractors, partners — reaches its resources. It works by defining an identity once for each user, hanging attributes off that identity, and making every system verify against it rather than keep a list of its own. The load-bearing word is approach: it is a discipline and an architecture, not a box on a network diagram. A registration authority is an entity; PKIX management is a set of protocol functions; identity management is an approach. That three-way discrimination is the whole question when it is asked.

Federated identity takes the same idea across an organisational boundary, so a user authenticated at their own institution can be admitted to a service run by someone else. The role vocabulary is worth learning as a set, because a question will hand you one definition and offer the others as distractors:

• Principals — the users or entities being identified.
• Identity providers — authenticate a principal and vouch for that identity to others.
• Attribute providers — hold and assert attributes about a principal ("is enrolled", "is over 18", "is a staff member").
• Service providers, also called relying parties — deliver the actual service and consume the assertion.
• Data consumers — the parties that read the assertions identity and attribute providers issue, decide authorization on them, and log the outcome for audit.

Single sign-on is the benefit the user notices. SAML is the classical assertion format that carries it. On the modern web the same job is done by OAuth 2.0 (RFC 6749) for delegated authorization and OpenID Connect for authentication on top of it — worth knowing exists, but beyond what this paper asks.

Worked example — one federated login, with every role named

A student at Northgate University opens a journal publisher's site and clicks an article.

1. The service provider (the publisher) does not know who this is, and redirects the browser to Northgate's identity provider.
2. The student — the principal — authenticates at Northgate, on Northgate's own login page. The publisher never sees the password, which is the point of the arrangement.
3. Northgate's identity provider returns a signed assertion: this principal is authenticated, and here are some attributes. An attribute provider — the library's entitlement system — supplies "member of a subscribing institution" without disclosing the student's name.
4. The publisher's access-control component is the data consumer: it reads the asserted attributes and makes an authorization decision ("subscribing institution ⇒ grant"), and writes an audit record of the access.

Notice what the last role is not. The service provider delivers the article; the data consumer is the part that obtains and employs the asserted data to decide and to log. That is the distinction the definition is built around.