Chapter 19 — Cryptography and trust services: scope and theory

Lesson map

Lesson 19 published. Map, example, EX055.

flowchart TD
  N0["Learning outcomes"]
  N1["19.1 What trust services are"]
  N2["19.2 Delegated trust"]
  N3["19.3 What assertions mean"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX055"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["19.1 What trust services are"]
  N2["19.2 Delegated trust"]
  N3["19.3 What assertions mean"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX055"]

[Learning outcomes]
    |
    v
[19.1 What trust services are]
    |
    v
[19.2 Delegated trust]
    |
    v
[19.3 What assertions mean]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX055]

Learning outcomes

You will (1) define the scope of trust services; (2) explain public-key infrastructure as a theory of delegated trust; (3) describe what certificates and timestamps assert.

19.1 What trust services are

Trust services help people and systems rely on electronic information: certificate authorities issue certificates; timestamping services prove when data existed; signature services help create and validate digital signatures; and key management services protect keys. Priya maps which Tidewell uses: a public authority for its websites, an internal authority for staff devices, and a signing service for contracts with publishers. Each service makes an assertion others rely on, so its own security and procedures become part of everyone's security. Priya records each assertion in a table.

19.2 Delegated trust

Public-key infrastructure delegates trust. A browser cannot know every website's key, so it trusts a small set of root authorities, which vouch for intermediates, which vouch for websites. RFC 5280 defines how certificates chain and how clients validate them. Priya explains the theory's weak point: any trusted root can issue a certificate for any name, so one compromised or careless authority can undermine everyone. Certificate Transparency, specified in RFC 6962, responds by making issuance public so misissued certificates can be detected. She shows staff how to view CT entries.

19.3 What assertions mean

A certificate asserts that a public key belongs to a name for a period; it does not assert that the named party is honest. A timestamp asserts that data existed at a time, not that the data is true. A signature asserts that the holder of a private key approved specific bytes, not that the holder understood them. Priya writes these distinctions for Tidewell's contract process, where staff sometimes assumed a signed PDF meant the publisher had agreed to terms that were actually in an unsigned attachment.

Worked example

Priya maps Tidewell's trust services, explains delegated trust and Certificate Transparency, and clarifies that a signature covers only the signed bytes in a contract case.

Synthetic case. Tidewell's services and contract are invented; RFC 5280 and RFC 6962 are real.

Errors and limits

Trusting many roots widens risk. Signatures prove approval of bytes, not intent or understanding.

Exercises

• EX055 — Four services. Name four kinds of trust service.
  Show marking criteria

  Rubric: 3 = certificate authorities, timestamping, signature services, key management;; 2 = three;; 1 = one;; 0 = none.
• EX056 — Root weakness. What is the main weakness of delegated trust?
  Show marking criteria

  Rubric: 3 = any trusted root can issue for any name, so one bad authority undermines all;; 2 = any root;; 1 = vague;; 0 = none.
• EX057 — Contract misunderstanding. What did staff misunderstand about the signed PDF?
  Show marking criteria

  Rubric: 3 = assumed signature covered terms in an unsigned attachment;; 2 = coverage;; 1 = vague;; 0 = none.

Synthesis

Trust services make specific assertions; understanding exactly what each asserts prevents misplaced reliance.

Continue studying — chapter 19 of 40

← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →