Authenticate one record before delivering bytes
05The HTTP body carries a clear binary header followed by one encrypted record. The receiver must authenticate the record and check its final padding delimiter.
For the valid published sample, authenticated decryption and delimiter 0x02 both pass. The receiver removes the delimiter and padding and delivers the original 41 message bytes to its application.
Source for this drawing: RFC 8291 · Read RFC section 4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Receiving ciphertext is different from accepting the application message.
- The binary header is 86 bytes: salt(16), record size rs(4), idlen(1), and the sender public key keyid(65). rs is an unsigned 32-bit network-order value; idlen is 65 and keyid begins with 0x04.
- The application server MUST encrypt one record and MUST set rs strictly greater than plaintext length + delimiter(1) + zero padding + GCM tag(16). The receiver is not required to support multiple records and MAY ignore rs.
- The sole final-record delimiter is 0x02, followed by any zero padding. The receiver MUST check the delimiter and discard other values. Authenticated decryption failure must not release message bytes.
- The HTTP Content-Encoding field has one value, aes128gcm. The sender MUST NOT use other content codings, including compression or repeated aes128gcm values.
- The RFC’s sample body decodes to 144 bytes: header 86 + plaintext 41 + delimiter 1 + tag 16, with no extra zero padding. Reported editorial erratum 5230 proposes correcting the printed Content-Length 145 to 144; its status is Reported, not Verified.
RFC 8188 §§ 2–2.1 supplies the coding header, AEAD tag and zero-padding layout. The rs sender constraint is strict >, not ≥; the binary keyid here is a public point, not a UTF-8 name. The displayed fixed values are public RFC test data, not keys to reuse for real messages. These illustrations do not send notifications or implement a production encryptor.
Read the RFC section ↗