Composable Event Streaming Representation (CESR)

1.1. Composability

Composability as defined here is short for text-binary concatenation composability. An encoding has composability when any set of self-framing concatenated primitives expressed in either the text domain or binary domain may be converted as a group to the other domain and back again without loss. Essentially composability provides round-trippable lossless conversion between text and binary representations of any set of concatenated primitives when converted as a set not merely individually. The property enables a stream processor to safely convert en-masse a a stream of text primitives to binary for compact transmission that the stream processor at the other end may safely convert back to text en-masse for further processing or archival storage as text. With the addition of group framing codes as composable primitives, such a composable encoding protocol enables pipelining (multi-plexing and de-multiplexing) of streams in either text or compact binary. This allows management at scale for high-bandwidth applications that benefit from core affinity off-loading of streams [Affinity].¶

1.2. Abstract Domain Representations

The cryptographic primitives defined here (i.e. CESR) inhabit three different domains each with a different representation. The first domain we call streamable text or text and is denoted as T. The third domain we call streamable binary or binary and is denoted as B. Composability is defined between the T and B domains. The third domain we call raw and is denoted as R. The third domain is special because primitives in this domain are represented by a pair or two tuple of values namely (text code, raw binary). The text code element of the R domain pair is string of one or more text characters that provides the type and size information for the encoded primitive when in the T domain. Actual use of cryptographic primitives happens in the R domain using the raw binary element of the (code, raw binary) pair. Cryptographic primitive values are usually represented as strings of bytes that represent very large integers. Cryptographic libraries typically assume that the inputs and outputs of their functions will be such strings of bytes. The raw binary element of the R domain pair is such a string of bytes.¶

A given primitive in the T domain is denoted with t. A member of an indexed set of primitives in the T domain is denoted with t[k]. Likewise a given primitive in the B domain is denoted with b. A member of an indexed set of primitives in the B domain is denoted with b[k]. Similarly a given primitive in the R domain is denoted with r. A member of indexed set of primitives in the R domain is denoted with r[k].¶

R->T(R)->T->B(T)->B->R(B)->R

R->B(R)->B->T(B)->T->R(T)->R

t[0] + t[1] + t[2] + t[3] = (t[0] + t[1]) + (t[2] + t[3])

T(cat(b[k]))=cat(T(b[k])) and B(cat(t[k]))=cat(B(t[k])) for all k

B(t[0] + t[1]) = B(t[0]) + B(t[1]) = b[0] + b[1]

T(b[0] + b[1]) = T(b[0]) + T(b[1]) = t[0] + t[1]

2.1. Stable Text Type Codes

There are many coding schemes that could satisfy the composability constraint of alignment on 24 bit boundaries. The main reason for using a T domain centric encoding is higher usability or human friendliness. Indeed a primary design goal of CESR is to select an encoding approach that provides such high usability or human friendliness in the T domain. This type of usability goal is simpley not realizable in the B domain. The B domain's purpose is merely to provide convenient compactness at scale. We believe usability in the T domain is maximized when the type portion of the prepended framing code is stable or invariant. Stable type coding makes it much easier to recognize primitives of a given type when debugging source, reading messages, or documents in the T domain that include encoded primitives. This is true even when those primitives have different lengths or values. For primitive types that have fixed lengths, i.e. all primitives of that type have the same length, stable type coding aids not only visual type but visual size recognition.¶

Usability of stable type coding is maximized when the type portion appears first in the framing code. Stability also requires that for a given type, the type coding portion must consume a fixed integer number of characters in the T domain. To clarify, as used here, stable type coding in the T domain never shares information bits with either length or value coding in any given framing code character and appears first in the framing code. Stable type coding in the T domain translates to stable type coding in the B domain except that the type coding portion of the framing code may not respect byte boundaries. This is an acceptable tradeoff because binary domain parsing tools easily accommodate bit fields and bit shifts while text domain parsing tools no not. By in large text domain parsing tools only process whole characters. This is another reason to impose a stability constraint on the T domain type coding instead of the B domain.¶

2.2. Code Characters and Lead Bytes

There are two ways to provide the required alignment on 24 bit boundaries to satisfy the composability property. The first way is to increase the size of text code to ensure that the T domain primitive has a total size (length) that is an integer multiple of 4 (text code sizing). The other way is to increase the size of the raw binary value by pre-pending leader bytes of zeros to the raw binary value before conversion to Base64 to ensure the total size of the raw binary value with pre-pended leader bytes is an integer multiple of 3 bytes (pre-conversion raw binary sizing). This ensures that size in characters of the Base64 conversion of the raw binary with leader bytes is an integer multiple of 4 characters. In this later case therefore the length of the pre-pended type code MUST be an integer multiple of 4 characters so that the total length of the T domain primitive with code and converted raw binary is an integer multiple of 4 characters.¶

The first way (text code sizing) may be more compact in some cases. The second way (pre-conversion raw binary sizing) may be easier to compute in some cases. In order to avoid confusion with the use of the term pad, we use the term leader or lead bytes when adjusting the raw binary size pre-conversion. The term pad may be confusing not merely because both ways use a type of padding but it is also true that the the number of pad characters when padding post-conversion equals the number of lead bytes when padding pre-conversion.¶

Suppose for example the raw binary value is 32 bytes in length. The next higher integer multiple of 3 is 33 bytes. Thus 1 additional lead byte is needed to make the size (length in byte) of raw binary an integer multiple of 3. The 1 lead byte makes that combination a total of 33 bytes in length. The resultant Base64 converted value will be 44 characters in length, which is an integer multiple of 4 characters. In contrast, recall that when we convert a 32 byte raw binary value to Base64 the converted value will have 1 pad character which may be replaced with a text code character. In both cases the resultant length in Base64 is 44 characters.¶

Whereas a 64 byte sized raw binary needs 2 lead bytes to make the combination 66 bytes in length where 66 is the next integer multiple of 3 greater than 64. When converted the result is 88 characters in length. The number of pad characters added on the result of the Base64 conversion of a 64 byte raw binary is also 2.¶

In summary we can use either pre-conversion lead byte sizing or post-conversion pad character sizing in our coding scheme to ensure composable 24 bit alignment.¶

2.3. Multiple Code Table Approach

The design goals for CESR framing codes include minimizing the framing code size for the most frequently used (most popular) codes while also supporting a sufficiently comprehensive set of codes for all foreseeable current and future applications. This requires a high degree of both flexibility and extensibility. We believe this is best achieved with multiple code tables each with a different coding scheme that is optimized for a different set of features instead of a single one-size-fits-all scheme. A specification that supports multiple coding schemes may appear on the surface to be much more complex to implement but careful design of the coding schemes can reduce implementation complexity by using a relatively simple single integrated parse and conversion table. Parsing in any given domain given stable type codes may then be implemented with a single function that simply reads the appropriate type selector in the table to know how to parse and convert the rest of primitive.¶

3.1. Text Code Size

Recall from above, the R domain representation is a pair(text code, raw binary). The text code is stable and begins with one or more Base64 characters that provide the primitive type may also include one or more additional characters that provide the length. The actual usable cryptographic material is provided by the raw binary element. The corresponding T domain representation of this pair is created by first converting the raw binary element to Base64, then stripping off any Base64 pad characters then finally prepending the text code element to the result of the conversion.¶

When the length of a given naive binary string is not an integer multiple of three bytes, standard Base64 conversion software appends one or two pad characters to the resultant Base64 conversion.¶

With pad characters, a set of Base64 strings resulting from the subsequent conversions of a set of binary strings could be concatenated and then converted back to binary en masse while preserving byte boundaries. In order to preserve byte boundaries the pad characters MUST be stripped in the conversion. Because the pad characters are stripped, this approach does not provide two-way or true composability as defined above. The number of pad characters is a function of the length of the binary string. Let N be the length the string. When N mod 3 = 1 then there are 8 bits in remainder that must be encoded into Base64. Recall the examples above, a single byte (8 bits) require two Base64 characters. The first encodes 6 bits and the second the remaining 2 bits for a total of 8 bits. The last character is selected such that its non-coding 4 bits are zero. Thus two additional pad characters are required to pad out the resulting conversion so that its length is an integer multiple of 4 Base64 characters. When N mod 3 = 2 then two bytes (16 bits) require three Base64 characters. The first two encode 6 bits each (for 12 bits) and the third encodes the remaining 4 bits for a total of 16. The last character is selected such that its non-coding 2 bits are zero. Thus one additional pad character is required to pad out the resulting conversion so that is length is an integer multiple of 4 characters. When N mod 3 = 0 then the binary string is aligned on a 24 bit boundary and no pad characters are required to ensure the length of the Base64 conversion is an integer multiple of 4 characters.¶

The number of requred Base64 pad characters to ensure that a given conversion to Base64 has a length that is an integer multiple of 4 may be computed with the following formula:¶

ps = (3 - (N mod 3)) mod 3), where ps is the pad size and N is the size in bytes of the binary string.¶

Recall that composability is provided here by prepending text codes that are of the appropirate length to ensure 24 bit boundaries in both the T and the corresponding B domain. The advantage of this approach is that naive Base64 software tooling may be used to convert back and forth between the T and B domains, i.e. T(B) is naive Base64 encode and B(T) is naive Base64 decode. In other words CESR primitives are compatible with existing Base64 (RFC-4648) tooling. Whereas new software tooling is needed for conversions between the R and T domains, e.g. T(R) and R(T and the R and B domains, e.g. B(R) and R(B).¶

This pad size computation is also useful for computing the size of the text codes. Because true composability also requires that the T domain value MUST be an integer multiple of 4 characters in length the size of the text code MUST also be function of the pad size, ps, and hence the length of the raw binary element, N. Thus the size of the text code in Base64 characters is a function of the equivalent pad size determined by the length N mod 3 of the raw binary value. If we let M be a non-negative integer valued variable then we have three cases:¶

The minimum code sizes are 1, 2, and 4 characters for pad sizes of 1, 2, and 0 characters with M equal 0, 0, and 1 respectively. By increasing M we can have larger code sizes for a given pad size.¶

3.2. Count, Group, or Framing Codes

As mentioned above one of the primary advantages of a composable encoding is that special framing codes can be specified to support groups of primitivies. Grouping enables pipelining. Other suitable terms for these special framing codes are group codes or count codes. These are suitable because they can be used to count characters, primitives in a group, or count groups of primitives in a larger group. We can also use count codes as separators to organize a stream of primitives or to interleave non-native serializations. A count code is its own primitive. But it is a primitive that does not include a raw binary value, only the text code. Because a count code's raw binary element is empty, its pad size is always 0. Thus a count code's size is always an integer multiple of 4 characters i.e. 4, 8, etc.¶

3.3. Interleaved Non-CESR Serializations

One extremely useful property of CESR is that special count codes enable CESR to be interleaved with other serializations. For example, Many applications use [JSON], [RFC4627], [CBOR], [RFC8949], or MsgPack [MGPK] to serialize flexible self-describing data structures based on hash maps, also know as dictionaries. With respect to hash map serializations, CESR primitives may appear in two different contexts. The first context is as a delimited text primitive inside of a hash map serialization. The delimited text may be either the key or value of a (key, value) pair. The second context is as a standalone serialization that is interleaved with hash map serializations in a stream. Special CESR count codes enable support for the second context of interleaving standalone CESR with other serializations.¶

3.4. Cold Start Stream Parsing Problem

After a cold start a stream processor looks for framing information to know how to parse groups of elements in the stream. If that framing information is ambiguous then the parser may become confused and require yet another cold start. While processing a given stream a parser may become confused especially if a portion of the stream is malformed in some way. This usually requires flushing the stream and forcing a cold start to resynchronize the parser to subsequent stream elements. Better yet is a re-synchronization mechanism that does not require flushing the in-transit buffers but merely skipping to the next well defined stream element boundary in order to execute cold start. Good cold start re-synchronization is essential to robust performant stream processing.¶

For example, in TCP a cold start usually means closing and then reopening the TCP connection. This flushes the TCP buffers and sends a signal to the other end of the stream that may be interpreted as a restart or cold start. In UDP each packet is individually framed but a stream may be segmented into multiple packets so a cold start may require an explicit ack or nack to force a restart.¶

Special CESR count codes support re-synchronization at each boundary between interleaved CESR and other serializations like JSON, CBOR, or MGPK¶

3.5. Compact Fixed Size Codes

As mentioned above, CESR uses a multiple code table design that enables both size optimized text codes for the most popular primitive types and extensible universal support for all other primitive types. Modern cryptographic suites support limited sets of raw binary primitives with fixed (not variable) sizes. The design aesthetic is based on the understanding that there is a minimally sufficient cryptographic strength and more cryptographic strength is just wasting computation and bandwidth. Cryptographic strength is measured in bits of entropy which also corresponds to the number trials that must be attempted to succeed in a brute force attack. The accepted minimum for cryptographic strength is 128 bits of entropy or equivalently 2**128 (2 raised to the 128th power) brute force trials. The size in bytes of a given raw binary primitive for a given modern cryptographic suite is usually directly related to this minimum strength of 128 bits (16 bytes). For example the raw binary primitives from the well known [NaCL] ECC (Elliptic Curve Cryptography) library all satisfy this 128 bit strength goal. In particular the digital signing public key raw binary primitives for EdDSA are 256 bits (32 bytes) in length because well known algorithms can reduce the number of trials to brute force invert an ECC public key to get the private key by the square root of the number of scalar multiplications which is also related to the size of both the private key and public key coordinates (discrete logarithm problem [DLog]). Thus 256 bit (32 byte) ECC keys are needed to achieve 128 bits of cryptographic strength. In general the size of a given raw binary primitive is typically some multiple of 128 bits of cryptographic strength. This is also true for the associated EdDSA raw binary signatures which 512 bits (64 bytes) in length.¶

Similar scale factors exist for cryptographic digests. A standard default Blake3 digest is 256 bits (32 bytes) in length in order to get 128 bits of cryptographic strength. This is also true of SHA3-256. Indeed the sweet spots for modern cryptographic raw primitive lengths are 32 bytes for many digests as well as EdDSA public keys and 64 bytes for EdDSA and ECDSA-secp256k1 signatures and 64 byte variants of the most popular digests. Therefore optimized text code tables for these two sweet spots (32 and 64 bytes) would be highly advantageous.¶

A 32 byte raw binary value has a pad size of 1 character.¶

(3 - (32 mod 3)) mod 3) = 1

Therefore the minimal text code size is 1 character for 32 byte raw binary cryptographic material and all other raw binary material values whose pad size is 1 character.¶

A 64 byte raw binary value has a pad size of 2 characters.¶

(3 - (64 mod 3)) mod 3) = 2

Therefore the minimal text code size for is 2 characters for 64 byte raw binary cryptographic material and all other raw binary material values whose pad size is 1 character. For example a 16 byte raw binary value also has a pad size of 2 characters.¶

For all other cryptographic material values whose pad size is 0, then the minimium size text code is 4 characters. So the minimally sized texts code tables are 1, 2, and 4 characters respectively.¶

Given that a given cryptographic primitive type has a known fixed raw binary size then we can efficiently encode that primitive type and size with just the type information. The size is given by the type.¶

So for example an Ed25519 (EdDSA) raw public key is always 32 bytes so knowing that the type is Ed25519 public key implies the size of 32 bytes and a pad size of 1 character that therefore may be encoded with a 1 character text code. Likewise an Ed25519 (EdDSA) signature is always 64 bytes so knowing that the type is Ed25519 signature implies the size of 64 bytes and a pad size of 2 characters that therefore may be encoded with a 2 character text code.¶

3.6. Code Table Selectors

In order to efficiently parse a stream of primitives with types from multiple text code tables the first character in the text code must be a code table selector character. Thus the 1 character text code table must do double duty. It must provide selectors for the different text code tables and also provide type codes for the most popular primitives that have a pad size of 1. There are 64 Base64 characters (64 values). We only need 12 tables to support all the codes and code formats needed for the foreseeable future. Therefore only 12 of those characters need be dedicated as code table selectors that leaves 52 characters that may be used for 1 character type codes. This gives a total of 13 type code tables consisting of the dual purpose 1 character selector table and 12 other tables.¶

As described above the selector characters for the framing or count code tables that best support interleaved JSON, CBOR, and MGPK are - and _. We use the numerals 0 through 9 to each serve as a selector. That leaves the letters A through Z and a through z as single character selectors. This provides 52 unique type codes for fixed length primitive types with raw binary values that have a pad size of 1.¶

To clarify, the first character of any primitive is either a selector or a 1 character code type. The characters 0 through 9, - and _ are selectors that select a given code table and indicate the number of remaining characters in the text code.¶

3.7. Small Fixed Raw Size Tables

There are two special tables that are dedicated to the most popular fixed size raw binary cryptographic primitive types. These are the most compact so they optimize bandwidth but only provide a small number of total types. In both of these the text code size equals the number of pad characters, i.e. the pad size.¶

3.8. Large Fixed Raw Size Tables

The three tables in this group are for large fixed raw size primitives. These three tables use 0, 1 or 2 lead bytes as appropriate for a pad size of 0, 1 or 2 for a given fixed raw binary value. The text code size for all three tables is 4 characters. The selector not only encodes the table but also implicitly encodes the number of lead bytes. With 3 characters for each unique type code, each table provides 262,144 unique type codes. This should be enough type codes to accommodate all fixed raw size primitive types for the foreseeable future.¶

3.9. Small Variable Raw Size Tables

Although many primitives have fixed raw binary sizes especially those for modern cryptographic suites such as keys, signatures and digests, there are other primitives that benefit from variable sizing such as encrypted material. Indeed CESR is meant to support not only cryptographic material types but other basic types such as generic text strings. These benefit from variable size codes.¶

The three tables in this group are for small variable raw size primitives. These three tables use 0, 1 or 2 lead bytes as appropriate given the pad size of 0, 1 or 2 for a given variable size raw binary value. The text code size for all three tables is 4 characters. The first character is the selector, the second character is the type, and the last two characters provide the size of the value as a Base64 encoded integer. The number of unique type codes is 64. A given type code is repeated in each table for the same type. What is different for each table is the number of lead bytes. The selector not only encodes the table but also implicitly encodes the number of lead bytes. The variable size is measured in quadlets of 4 characters each in the T domain and equivalently in triplets of 3 bytes each in the B domain. Thus computing the number of characters when parsing or off-loading in the T domain means multiplying the variable size by 4. Computing the number of bytes when parsing or off-loading in the B domain means multiplying the variable size by 3. The two Base64 size characters provide value lengths in quadlets/triplets from 0 to 4095 (64**2 -1). This corresponds to value lengths of up to 16,380 characters (4095 * 4) or 12,285 bytes (4095 * 3).¶

3.10. Large Variable Raw Size Tables

Many legacy cryptographic libraries such as OpenSSL and GPG support any sized variable sized primitive for keys, signatures and digests. Although this approach is often criticized for providing too much flexibility, many legacy applications depend on this degree of flexibility. Consequently these large variable raw size tables provide a sufficiently expansive set of tables with enough types and sizes to accommodate all the legacy cryptographic libraries as well as all the variable sized raw primitives for the foreseeable future.¶

The three tables in this group are for large variable raw size primitives. These three tables use 0, 1 or 2 Lead bytes as appropriate for the associated pad size of 0, 1 or 2 for a given variable sized raw binary value. The text code size for all three tables is 8 characters. The first character is the selector, the next three characters provide the type, and the last four characters provide the size of the value as a Base64 encoded integer. With 3 characters for each unique type code, each table provides 262,144 unique type codes. This should be enough type codes to accommodate all fixed raw size primitive types for the foreseeable future. A given type code is repeated in each table for the same type. What is different for each table is the number of lead bytes. The selector not only encodes the table but also implicitly encodes the number of lead bytes. The variable size is measured in quadlets of 4 characters each in the T domain and equivalently in triplets of 3 bytes each in the B domain. Thus computing the number of characters when parsing or off-loading in the T domain means multiplying the variable size by 4. Likewise computing the number of bytes when parsing or off-loading in the B domain means multiplying the variable size by 3. The four Base64 size characters provide value lengths in quadlets/triplets from 0 to 16,777,215 (64**4 -1). This corresponds to value lengths of up to 67,108,860 characters (16777215 * 4) or 50,331,645 bytes (16777215 * 3).¶

3.11. Count (Framing) Code Tables

There may be as many at 13 count code tables, but only two are currently specified. These two are the small count, four character table and the large count, eight character table. Because count codes only count quadlets/triplets, primitives or groups of primitives, count codes have no value component, but only type and size components. Because primitives are already guaranteed to be composable count codes do not need to account for pad size as long as the count code itself is aligned on a 24 bit boundary. The count code type indicates the type of primitive being counted and the size indicates how many of that type. Both count code tables use the first two characters as a nested set of selectors. The first selector uses- as the initial selector for count codes. The next character is either a selector for another count code table or is the type for the small count code table. When the second character is numeral 0 - 9 or the letters - or _ then it is a secondary cound code table selector. When the second character is a letter in the range A - Z or a - z then it is a unique count code type. This given a total of 52 single character count code types.¶

3.12. Op Code Tables

The _ selector is reserved for the yet to be defined op code table or tables. Op codes are meant to provide stream processing instructions that are more general and flexible than simply concatenated primitives or groups of primitives.¶

3.13. Selector Codes and Encoding Schemes

The following table summarizes the T domain coding schemes for the 13 code tables defined above.¶

* selector character is also type character¶

Character format symbol definitions:
$ means type code character from subset of Base64 [A-Z,a-z,0-9,-,_].
# means a Base64 digit as part of a base 64 integer that determines the number of following quadlets or triplets in the primitive or when part of a count code, the count of following primitives or groups of primitives.
& represents one or more Base64 value characters representing the converted raw binary value included lead bytes when applicable. The actual number of chars is determined by the prep-ended text code.
TBD means to be determined¶

3.14. Parse Size Table

Text domain parsing can be simplified by using a parse size table. A text domain parser uses the first character selector code to look up the hard size (stable) portion of the text code. The parse then extracts hard size characters from the text stream. These characters form an index in to the parse size table which includes a set of sizes for the remainder of the primitive. Using these sizes for a given code allows a parser to extract and convert a given primitive. In the binary domian the same text parse table may be used but each size value represents a multiple of a sextet of bits instead of Base64 characters. Example entries from that table are provided below. Two of the rows may always be calculated given the other 4 rows so the table need only have 4 entries in each row. Thus all basic primitives may be parsed with one parse size table.¶

* size may be calculated from other sizes.
# size may be calculated from extracted code characters given by other sizes.¶

hs means hard size in chars.
ss means soft size in chars.
cs means code size where cs = hs + ss.
vs means value size in chars.
fs means full size in chars where fs = hs + ss + vs.
ls means lead size in bytes.
ps means pad size in chars.
rs means raw size in bytes of binary value.
bs means binary size in bytes where bs = as + rs.¶

3.15. Special Context Specific Code Tables

The table above that provides the encoding schemes each with an associated code table that provides the type codes or set of codes for each associated primitive type. These coding schemes constitute the basic set of code tables. This basic set may be extended with context specific code tables. The context in which a primitive occurs may provide an additional implicit selector that is not part of the actual explicit text code. This allows context specific coding schemes that would otherwise conflict with the basic code tables. Currently there is only one context specific coding scheme, that is, for indexed signatures. A common use case are thresholded multi-signature schemes. A threshold satisficing subset of signatures belonging to an ordered or list of public keys may be provided as part of stream of primitives. One way to compactly associated each signature with its public key is to include in the text code for that signature the index into the ordered set of public keys. The typical raw binary size for signatures is 64 bytes which has a pad size of 2. This gives two code characters for a compact text code. The first character is the selector and type code. The second character is Base64 encoded integer index. By using a similar dual selector type code character scheme as above, where the selectors are the numbers 0 -9 and - and _. Then there are 52 type codes given by the letters A - Z and a - z. The index has 64 values which supports up to 64 members in the public key list. A selector can be used to select a large text code with more characters dedicated to larger indicies. Current only a small table is defined.¶

A new signature scheme based on Ed448 with 114 byte signatures signatures is also supported. These signatures have a pad size of zero so require a four charactor text code. The first characters is the selector 0, the second characters is the type with 64 values, the last two characters provide the index as a Base64 encoded integer with 4096 different values.¶

The associate indexed schemes are provided in the following table.¶

* selector character is also type character¶

Character format symbol definitions:
$ means type code character from subset of Base64 [A-Z,a-z,0-9,-,_].
# means a Base64 digit as part of a base 64 integer that determines the index.
& represents one or more Base64 value characters representing the converted raw binary value included lead bytes when applicable. The actual number of chars is determined by the prep-ended text code.
TBD means to be determined¶

4.1. Filling Code Table

The approach to filling the tables is a first needed first served basis. In addition the requirement that all cryptographic operations maintain at least 128 bits of cryptographic strength precludes the entry of many weak cryptographic suites into the compact tables. CESR's compact code table includes only best-of-class cryptographic operations. In 2022 it is expected that NIST will approve standardized post-quantum resistant cryptographic signatures at which time codes for the most appropriate post quantume signature suites will be added. Falcon appears to be the leader with open source code already available.¶

4.2. Description

This master table includes all three types of codes separated by headers. The table has 5 columns. These are as follows:¶

1) The Base64 stable (hard) text code itself. 2) A description of what is encoded or appended to the code. 3) The length in characters of the code. 4) the length in characters of the index or count portion of the code 5) The length in characters of the fully qualified primitive including code and append material or number of elements in group.¶

The table includes complex groups that are composed of other groups. For example consider the counter attachment group with code-F## where ## is replaced by the two character Base64 count of the number of complex groups.
This is known as the TransIndexedSigGroups counter. Within the complex group are one more more attached groups where each group consists of a triple pre+snu+dig followed by a ControllerIdxSigs group that in turn consists of a counter code -A## followed by one or more indexed signature primitives. The following example details how this complex group may appear.¶

The example has only one group. The example is annotated with comments, spaces and line feeds for clarity.¶

-FAB     # Trans Indexed Sig Groups counter code 1 following group
E_T2_p83_gRSuAYvGhqV3S0JzYEF2dIa-OCPLbIhBO7Y    # trans prefix of signer for sigs
-EAB0AAAAAAAAAAAAAAAAAAAAAAB    # sequence number of est event of signer's public keys for sigs
EwmQtlcszNoEIDfqD-Zih3N6o5B3humRKvBBln2juTEM      # digest of est event of signer's public keys for sigs
-AAD     # Controller Indexed Sigs counter code 3 following sigs
AA5267UlFg1jHee4Dauht77SzGl8WUC_0oimYG5If3SdIOSzWM8Qs9SFajAilQcozXJVnbkY5stG_K4NbKdNB4AQ         # sig 0
ABBgeqntZW3Gu4HL0h3odYz6LaZ_SMfmITL-Btoq_7OZFe3L16jmOe49Ur108wH7mnBaq2E_0U0N0c5vgrJtDpAQ    # sig 1
ACTD7NDX93ZGTkZBBuSeSGsAQ7u0hngpNTZTK_Um7rUZGnLRNJvo5oOnnC1J2iBQHuxoq8PyjdT3BHS2LiPrs2Cg  # sig 2