A monitor keys leaf certificates on serialNumber alone and treats authorityKeyIdentifier as proof of the issuer — what breaks?

A monitor ingesting certificates issued for a registry's own zone is reading structures nobody in the organisation created. Everything in them is an assertion, and the fields divide cleanly into two jobs: **naming** a thing, and **proving** a thing. Almost every design error in such a system comes from treating a naming field as a proof. ## serialNumber names one certificate, per issuer The profile's requirement is specific: `serialNumber` is a positive integer assigned by the CA, unique for each certificate **that CA** issues. The uniqueness scope is the issuer, not the world. So: - Two authorities can both issue a certificate with serial `03`, and both are conforming. - The identifying pair is `issuer` plus `serialNumber`. That pair, and not the serial alone, is what a revocation entry or a status query names. - The value is an integer that readers must be able to handle at up to 20 octets. A 64-bit column will silently truncate or loudly reject real certificates; store it as bytes or as text. Keying a store on the serial alone therefore produces collisions between unrelated authorities, and the failure is worse than a duplicate-key error: an upsert overwrites one authority's certificate with another's, and the record that remains is a chimera nobody issued. ## authorityKeyIdentifier and subjectKeyIdentifier are hints `subjectKeyIdentifier` carries a short value identifying the public key in this certificate. `authorityKeyIdentifier` carries the corresponding value for the key that is supposed to have signed it, and may also carry the issuer's name and serial. The profile suggests computing the value as a hash of the public key, but permits any method that identifies the key uniquely, and requires `authorityKeyIdentifier` to be non-critical. What they are for is **narrowing candidates**: when several keys could plausibly be the issuer's, the identifier says which one to try first. What they are not is evidence. Consider what a hostile or simply mistaken submitter can do: build a certificate, write any `authorityKeyIdentifier` into it, self-sign it, and hand it to your monitor. Every field parses. The identifier points confidently at a well-known authority. Nothing about that authority was involved. The only thing that establishes which key signed is verifying `signatureValue` over the `tbsCertificate` with a candidate public key — a different exercise, belonging to path validation, and one the identifier merely speeds up. ## The pointer extensions are strings, not services | Extension | What it holds | What it is in an unvalidated certificate | |---|---|---| | `authorityInfoAccess` with `id-ad-caIssuers` | Where the issuer's certificate may be fetched | A URL chosen by whoever built the certificate | | `authorityInfoAccess` with `id-ad-ocsp` | Where status may be requested | The same | | `cRLDistributionPoints` | Where a revocation list is published | The same | | `freshestCRL` | Where an incremental list is published | The same | Read as fields, they are useful metadata: a monitor can record which endpoints an authority advertises and notice when they change. Read as instructions, they are a request generator pointed wherever a submitter likes. An ingest path that dereferences every URL it finds in an unvalidated certificate has handed control of its outbound requests to its input, and that is before considering the volume a bulk feed can produce. Fetching them is a deliberate decision made after validation, with its own rules — and what to do with the results is a different subject entirely. ## What the monitor should record 1. The `issuer` name and `serialNumber` **as a pair**, which is the certificate's identifying tuple. 2. A digest over the certificate's canonical encoding, as a stable deduplication key that survives repackaging. 3. The `subjectAltName` entries, which are the names the registry actually cares about. 4. `notBefore` and `notAfter`, so an alert can be scoped to the window the issuer intended. 5. The pointer extensions and key identifiers as **untrusted strings**, recorded verbatim and dereferenced by nothing on the ingest path. ## The general rule The distinction generalises past this leaf. Fields that *name* — serial numbers, key identifiers, distinguished names, URLs — are copied into the structure by whoever assembled it, and a signature over them proves only that the signer was willing to sign that text. Fields that *prove* are cryptographic, and there is exactly one of them in a certificate. A senior answer says which of the two a given field is before saying anything else about it.