| Link | Commentary | Section |
|---|---|---|
| 0000 | X | Glossary, overview, how to use |
| 0001 | X | Prefixes, Derivation and derivation reference tables |
| 0002 | X | Data model (field & event concepts and semantics) |
| 0003 | X | Serialization |
| 0004 | X | Key Configuration (Signing threshold & key set) |
| 0005 | X | Next Key Commitment (Pre-Rotation) |
| 0006 | X | Seals |
| 0007 | X | Delegation (pending PR by Sam) |
| 0008 | X | Key-Event State Machine |
| 0009 | X | Indirect Mode & Witnesses |
| 0010 | Recovery/consensus Algorithm (KAACE) | |
| 0011 | Database & Storage Considerations | |
| 0097 | n/a | Non-Normative Implementation Guidance |
| 0098 | n/a | Use Cases |
| 0099 | n/a | Test Vectors and Normative Statement Index |
{definition from page 36:}A "seal" is a qualified digest. Its derivation code specifies what type of hashing function was used but does not include any other information about the associated data. The hashing step produces a digest of the serialized data that is referenced by the seal. The seal acts as an anchor of the data. To clarify, the actual data is not provided explicitly in the seal, but merely the digest of the serialized data, hence the data is hidden. This may be useful in making verifiable cryptographic commitments at the location of an event to data stored and/or disclosed elsewhere.
A "seal" expresses a cryptographic commitment in the form of a cryptographic digest or hash tree root (Merkle root) that anchors arbitrary data or a tree of hashes of arbitrary data to a particular event in the key event sequence. This is referred to as a "seal" because, like a real-world seal, it offers a simple and direct proof of authenticity. Specifically, a key event sequence (made up entirely of a sequence of seals) provides a verifiable proof of current control authority at the location of each event in the key event sequence.
NOTE: A seal is an ordered self-describing data structure. Abstractly, this means each element of the seal has a tag or label that describes the associated element’s value. There are four normative types of seals: these are digest, root, event, and location seals.
-
A digest seal include a digest of external data. This minimal seal has an element whose label indicates that the value is a digest. The value is fully qualified Base64 with a prepended derivation code that indicates the type of hash algorithm used to create the digest.
-
A root seal provides the hash tree root of external data. This minimal seal has an element whose label indicates that the value is the root of a hash tree. The value is fully qualified Base64 with a prepended derivation code that indicates the type of hash algorithm used to create the hash root.
- Note: In order to preclude second pre-image attacks, hash trees used for hash trees roots in KERI seals MUST be sparse and of known depth, similar to the requirements for certificate transparency [46; 68; 93– 95]. One simple way to indicate depth is that internal nodes in a sparse tree include a depth prefix that decrements with each level and must remain non-negative at a given leaf [46].
-
An event seal anchors one event to another event. It includes the identifier prefix, and a digest of an event in a key event log. The prefix and digest allow locating the event in an content-addressable database of events. The digest also allows confirmation of the anchored event contents. The two events may be either 1.) in the same key event sequence or 2.) in two different key event sequences with different identifier prefixes. In the latter case, a seal may provide a cryptographic commitment to some key event from some other key event.
-
An event location seal is similar to an event seal, and can be useful when two seals in two different events are cross-anchoring each other. A location seal includes the prefix, sequence number, ilk and prior digest from an event. These four values together uniquely identify the location of an event in a key event log. This provides a cross reference of one event to another where the other event’s digest must include the seal in the event contents so it cannot contain the first event’s digest but the digest of the preceding event.
- To clarify, digest creation means that only one of the cross anchors can include a complete digest of the other event. The other cross anchor must use a unique subset of data such as the unique location of the event. The ilk is required in the location because of the special case of recovery where a rotation event supersedes an interaction event.
- This is described in detail later under recovery.
- Location seals are also useful in external data that is anchored to an event log. The location seal allows the external data to include a reference to the event that is anchoring the external data’s contents. Because the anchoring event includes a seal with the digest of the external data, it is another form of cross anchor.
- To clarify, digest creation means that only one of the cross anchors can include a complete digest of the other event. The other cross anchor must use a unique subset of data such as the unique location of the event. The ilk is required in the location because of the special case of recovery where a rotation event supersedes an interaction event.
The data structure that provides the elements of a seal MUST have a canonical order so that it may be reproduced in a digest of elements of a event. Different types of serialization and/or encodings may provide different types of ordered mapping data structures. One universal canonical ordering data structure is a list of lists (or array of arrays) containing label/value pairs. The order of appearance in each list of each (label, value) pair is standardized and may be used to produce a serialization of the associated values.