Chapter 4 — Data models | Technologist Cryptography and trust services

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 4 — Data models

Lesson map

Lesson 04 published. Map, example, EX010.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 Modelling trust objects"]
  N2["4.2 Designing the table"]
  N3["4.3 Keeping secrets out"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX010"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 Modelling trust objects"]
  N2["4.2 Designing the table"]
  N3["4.3 Keeping secrets out"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX010"]

[Learning outcomes]
    |
    v
[4.1 Modelling trust objects]
    |
    v
[4.2 Designing the table]
    |
    v
[4.3 Keeping secrets out]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX010]

Learning outcomes

You will (1) model certificates, keys and owners as data; (2) design a simple inventory table; (3) keep sensitive values out of inventories.

4.1 Modelling trust objects

Rosa designs a data model for the council's certificates and keys. A certificate record holds the host name, issuer, serial number, expiry date, renewal method and owner. A key record holds its purpose, algorithm, location, creation date and owner. Each record has a unique identifier, and certificates link to the key they use. She deliberately stores no private keys or secrets in the model: the inventory describes keys, it never contains them. SP 800-57 Part 1 stresses that organisations must know their keys, and a well-designed model is the first step to that knowledge.

4.2 Designing the table

Using a lightweight database, Rosa creates tables for certificates, keys, owners and services, with relationships between them. She adds constraints: every certificate must have an owner and an expiry date; renewal method must be one of acme, internal-ca or manual. Constraints catch errors at entry time rather than during an outage. She imports existing spreadsheets and finds thirty rows with no owner, which she flags for follow-up. Owen notes that the act of loading data into a stricter model often reveals more than any report.

4.3 Keeping secrets out

A colleague asks whether the inventory could also store the passwords for service accounts "to keep everything in one place". Rosa explains why not: the inventory is read by many people, exported to reports and backed up widely, so storing secrets there would expose them. Secrets belong in a dedicated secret store with access control and audit logs. The inventory can record where a secret is stored and who owns it. Separating description from secret is a pattern she will reuse in every system she designs.

Worked example

Rosa's inventory model links certificates, keys, owners and services with constraints, finds thirty ownerless rows and refuses to store service passwords in it.

Synthetic case. The inventory is invented; SP 800-57 Part 1 is real.

Errors and limits

Inventories decay without updates from automation. Mixing secrets into descriptive data exposes them widely.

Exercises

EX010 — Certificate fields. List four fields of a certificate record. Rubric: 3 = four of host, issuer, serial, expiry, renewal method, owner;; 2 = three;; 1 = one;; 0 = none.
EX011 — Constraint benefit. Why add constraints such as requiring an owner? Rubric: 3 = catch errors at entry rather than during outages;; 2 = early errors;; 1 = slower;; 0 = none.
EX012 — Passwords request. Why must service passwords not go into the inventory? Rubric: 3 = widely read, exported and backed up; secrets belong in a secret store;; 2 = exposure;; 1 = fine;; 0 = none.

Synthesis

A clear data model for trust objects, enforced with constraints and kept free of secrets, makes keys and certificates manageable.

Continue studying — chapter 04 of 30

← Chapter 03 (draft) · Course chapter index · Chapter 05 (draft) →