CESR Composable Event Streaming Representation for CESR/KERI/ACDC/SPAC-TSP Protocol Stack and other Cryptographically Agile and Cryptographically Heavy Protocols Composable cryptographic material primitives and groups in dual text and binary streaming protocol design Samuel M. Smith Ph.D. F\ senerone &)
Resources
Documentation: TolP Public Review Specs https:/fgithub.comftrustoveripjtswg-cesr-specification https:/fgithub.comtrustoveripjtswg-keri-specification https://github.comftrustoverip/tswg-acdc-specification https://github.comtrustoveripitswe:-did-method-webs:-specification TolP Public Draft Specs. https:/fgithub.comftrustoverip/tswg-tsp-specification Community: (meetings, open source code, IETF internet drafts)
https:/jgithub.comWebOfTrust/keri
https:/jkeri.one/keri-resources/
Protocol Formats Internet Protocols Cryptographic Protocols Binary JSON or Hybrid JSON/MGPK UDP, TCP, DNS, RTP, RTCP, NTP, SNMP, BGP, BGMP, ARP, RAET, Secure Scuttlebutt, DIDCom IGMP, RIP, PING, WebRTC JSON/JOSE/JWT Family Text (line based) Binary Syslog, SMTP, POP, Telnet, NNTP, RTSP, IRC RLP (Ethereum) Text (header framed) Bitcoin HTTP, SIP (CBOR/COSE/CWT Family Inflection Point in Protocol Design (dual representation) Flexible Concatenable Binary Crypto Material XML, JSON (text self describing map) Noise (Signal) MGPK, CBOR (binary self describing map) Flexible Composable Concatenable Text/Binary Crypto Material CESR Composable Event Streaming Representation
Protocol Formats Truly secure protocols are both cryptographically agile and cryptographically primitive-heavy. High cryptographic usability and performance drive enhanced security. It avoids the false dilemma of trading down security for better developer usability and performance.
Binary vs Text Based Protocol Features Binary Format Advantages Compact, efficient, and performant Disadvantages: Difficult to develop, test, debug (over the wire), prove compliance, and extremely diffcult to fix and version Requires custom tooling especially over the wire debug, difficult to understand, and hard to gain adoption. Text Format (especiall self-describing field map based) Advantages: Easy to develop, test, debug (especially over the wire), and prove compliance, and extremely easy to fix and version Requires ittle custom tooling especially over the wire debug, easy to understand and easy to gain adoption. Disadvantages: Verbose, Inefficient, Non-performant Hybrid Both Text & Binary Formats (self describing map, Text=JSON and Binary=MGPK or CBOR) Advantages: Zero cost to switch between text and binary. Text for development and adoption. Binary for production use. Easy to develop, test, debug (especially over the wire), and prove compliance when text Requires ittle custom tooling especially over the wire debug, easy to understand Extremely easy to fix and version Easy to adopt as text with no additional barrier to binary adoption Fairly compact when binary, Fairly efficient when binary, fairly performant when binary
Composable Concatenable (Text/Binary) Event Streaming Representation (CESR) Hybrid Flexible Concatenated Compact Text Base64 & Binary Formats Advantages: Composable (any concatenated block in one format may be converted as a block to the other without loss, round trippable ) Zero cost to switch between text and binary. Text for development and adoption. Binary for production use. Flexible concatenation of heterogenous crypto material that preserves bytefchar boundaries between primitives Pipelined parsing and processing Stream or Datagram Fully qualified self-framing derivation codes for primitives. Fully qualified self-framing count codes for groups of primitives or groups of groups. Fully qualified self-framing count codes for pipelining groups. More compact text and binary than hybrid text and binary self-describing map based formats Fairly Easy to develop, test, debug (especially over the wire), and prove compliance when text Requires little custom tooling, especially over-the-wire debugging of text Fairly easy to understand when text Archivable audit-compliant, legally defensible text format Fairly easy to adopt as text with no additional barrier to binary adoption Compact when binary, Efficient when binary, Performant when binary Disadvantages: Almost as compact, efficient, and performant as non-composable tuned binary. More complex parsing,
Three native domains and formats
Raw Domain (text code, raw binary) (cryptographic operations) Raw binary representation that crypto libraries use
Text Domain fully qualified text, name-space able, streamable, archivable, envelopeable Cryptographic material: Cryptonyms (identifiers), public keys, digests, signatures etc. Includes any textual use of cryptographic material, Documents, VCs, Archives, Audit logs etc. Usable in over the wire streaming for development and debug. DKrJxkcRIm5ulxs33F5pxRIP6T7hIJEbhpHrUt1Ddhh0
Binary Domain (fully qualified binary) (streaming binary) Fully qualified binary representation of cryptographic material for efficient over the wire streaming
Round Trippable Closed loop Transformation S m e T2S 2 =T (") _ sar . ot =8 (') 0 composibe s ) oy =T (e +y) T A oy =S (e ) w ] $($4)-5x Kot N s 7(2),2 (e, rm) |
‘Why Composability Verifiable Text Stream = Verifiable Binary Stream (no loss of verifiability in mass conversion) Amount of cryptographic material in attachments may exceed cryptographic material in message bodies. Controller signatures, witness signatures, other receipt signatures, endorsement signatures. Replay of KELs must replay messages (key events) plus attachments (signatures) Want this replay to be compact, performant, and supported by bare metal protocols (TCP, UDP) Verifiable Credential world is Text Verifiable Authentic Data world human facing side is Text Verifiable Digitally Signed Contract world is Text Verifiable Audit Trail World is Text
Code Tables 3 classes of stable composable derivation codes: Basic material primitives, Indexed signature primitives or variable length values, Grouping count codes.
CESR Code Table Schemes o | Sobcor Tpechs | keSO et Ledes | Pedsin ot (Minimal Size) : ; 0 : 2 B sisniias + setestor character is alse type character 1 aans a bascéé Gigit as bart of a base 64 Lnteger that deterhirGs che mumbor of followlng quadlets or rapreserts one or more Sasesd value charsctars repressnting che corverced raw binary value included lesd
Parsing Size Tables Siza Table Selector Parse Size Tabie . - g | o B w . " 3 3 b‘ fi o I 1 f . p p v B ; W
- size may be calealated from otner sizes. § 3iza may be calcalated from cxtracted code characters given by other sizes. %5 means full size in chats where fs - hs ¢ 55 ¢ ve. 15 means lead size in byses. bs means binary size in bytes where b = 43 + rs.
Special Context Tables Special Indexed Primitive Table Selector Select TypeChars Index Code Size Lead Bytes Pad Size Format or Chars m—z,a—z]‘ o 1 2 0 2 stk 0 1 2 4 0 0 e * selector character is also type character $ means type code character from subset of Base64 [A-Z,a-2,0-9,-,_].
means a Base64 digit as part of a base 64 integer that determines the index.
& represents cne or more Base6l 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.
Example Simple Inception Key Event Message . 'v': 'KERICAACESRAAAA.',
16 BN Rn6dG KANAHS DGO TS TR 1T e,
e
bet: 'O,
B
et [,
ra': [l
Example Simple Inception Key Event Message Xicp f 't' message type Ilker Tag3 Ilk-icp
def denot (ams) : “MnDe-anrotate CESR stream seturns dns (bytes): deannotation of input annotated CESR message stream Parameters ams (str): CESR annotated message stream text dns = bytearray() # deannotated message stream lines = ame.splitlines() for line in lines: Line - Line.strip() front, sep, back - line.partition('#') ¥ finde comment if any front = front.strip() # non-commented portion strip white space if front: dns . extend (front.encode ()) return bytes (dans)
Example Inception Key Event Message
Example Inception Key Event Message
Size Comparison - Key Event Messages (GESR 2. Key Event Peformance Comparison (Ratos) Key Event CESR CESR CBOR MGPK JSON qb2 qb64 Inception Simple 1.00 1.33 1.46 1.46 1.83 Inception 1.00 1.33 1.42 1.42 1.56 Interaction 1.00 1.33 1.45 1.45 1.63 Rotation 1.00 1.33 1.42 1.42 1.58 Delegated Inception 1.00 1.33 1.42 1.42 1.58 Delegated Rotation 1.00 1.33 1.44 1.44 1.65 Average 1.00 1.33 1.44 1.44 1.64]
Crypto-Agile Comparison JSON/JOSE/JWK CBOR/COSE «Interior primitives inside messages are typically public keys and digests (Hashes). »Crypto Agility for Cryptographic Primitives in JSON using JOSE and CBOR using COSE. JSON/JOSE/CBOR/COSE Family: JWT/JWS[WELWK JCWT N b b o o it o et O e *The JOSE/COSE family only provides normative support for a limited set of key public types. ECDSAEDDSA RSAHMAC OES https://connectzid.comfproductsfnimbus-jose-wt/examples/jwk-generation https://pycose.readthedocs.iofenflatest/pycosefkeysjecz.html «Currently, JOSE and COSE do not provide normative support for Interior Hashes (not exterior HMACs as reputable signatures). But one could use a non-normative approach with similar data structure for digest algorithms or comparable size (256 bit) as Public keys.
JWK for Crypto Agility
Inception Example: 16 interior primitives of size of a key Overhead of JWK: diwk={
“kty" : "OKP",
o e,
o NATRREAYS TNGHOg hesPapiMIraaPCHURY,
"d" :"nWGxne_gWmC6hErokuwsxERJXWI7MmkZcDusAxyuf2A",
"use": "sig",
K PR CaUCBB 6P ZQACCBSLROb KRRV
}
Compact5ON= {kty""OKP","cry":"Ed25519","X":" 11GYAYKXCrfVS_7TyWQHOg7hcvPapiMirwlaaPcHURG","d": "iWGxne_gWmCEhErokuwsxERJX WI7MmKZeDusAxyuf2A" "use":"sig", "kid":"FdFYFzERWC2UCBB46PZQI4GGB5LUJRBObEKWRBICVQ"} Size =193 bytes. Overhondpo primie 19344 45 byes Overnend o i WK v G e 2384 Overhead ratio (JSON with JWK to JSON with CESR) = (2384+915) [ 915 = 3.61 Overhead ratio (JSON with JWK to gb2 CESR) = (2384+915) | 585 = 5.64
COSE for Crypto Agility
Inception Example: 16 interior primitives of size of a key ‘Overhead of COSE Key: {
'CURVE" 'P_256',
'ALG": 'ES256',
'D'; unhexlify(b'57¢92077664146€876760¢9520d054aa93¢3afb04e306705db6090308507b4d3') } <k = \xa6\x011x02\x038Ix01:XIxbalxcs\xbilx1cixadx8flxgg\xfolxc7+{x05\xcfKixgesdxd2Dixdcix1B\xgftR(xZ! x9alx86\xd6\xaoixgelxffXix131x8blxf8-ixc1ixbbixdsbixbelxofixas ixb7\x80J:dixb6\xd7, xcfixedkolxbsixed(ixbblxfcix11-#XWixcg WwiAFIxeBuvixocixgs\xdoTixaalxg3\xc3ixafixboNoglxos\xdb 1xg001x8s\xo7ixbatxd3 len(ck) == 105, Size =105 bytes e or it 10536 = G9iycs Overhead ratio (CBOR with COSE to CBOR with CESR) = (1104+829) / 829 = 2.33 Overhead ratio (CBOR with COSE to gb2 CESR) = (1104+829) [ 585 = 3.30
TSP Example https://github.com/WebOfTrust/keripy/discussions/612
Tritet Parsing CESR Parser Tritet Table Starting Tritet Serialization Character 06000 Annotated GESR ninte 0b001 CESR T Domain Count (Group) Code - 06010 CESR T Domain Op Code [ 0b011 JSON { 06100 MGPK 0b101 CBOR 0b110 MGPK ob111 CESR B Domain
Stream Parsing Rules
Stream start, cold restart, message end, group end: Examine tritet (3 bits). Each stream must start (restart) with one of 6 things:
Framing count code in efther Base64 or Binary.
Framing opcode n either Base64 or Binary
JSON encoded mapping.
CBOR encoded Mapping.
MGPK encoded mapping.
Annotated Base64 A parser merely needs to examine the first tritet (3 bits) of the first byte of the stream start to determine which one of the 6 itis. When the first tritet indicates its JSON, CBOR, or MGPK, then the included version string provides the remaining and confirming information needed to fully parse the associated encoded message. When the firsttritet is a framing code then, the remainder of framing code itself willinclude the remaining information needed to parse the attached group. The framing code may be in either Base64 or binary. When the first trivet is annotated qb64 then parser de-annotates streamjfile before parsing as above. At the end of the stream start, the stream must resume with one of the 6 things, either a new JSON, CBOR, o MGPK encoded mapping or another of two types of framing codes expressed in either Base64 or binary or annotated qb6d.