COAP-OSCORE-CONF(5)
π coap-oscore-conf(5) β the CoAP OSCORE configuration file format, explained by your fave β¨
Okay bestie, so this is the manual page for coap-oscore-conf β the config file format for OSCORE, and honestly it's giving "small file, big responsibilities" energy π
. Let's get into it.
πΈ NAME πΈ
coap-oscore-conf β the CoAP OSCORE configuration file format. That's it, that's the name, no cap.
β¨ DESCRIPTION β¨
So here's the tea: this OSCORE config file gets read in when you use the -E oscore_conf_file option with the coap-client(5) or coap-server(5) executables. And what does that do? It lets a client or server use OSCORE to protect the CoAP information between endpoints β that's RFC8613, bestie, look it up π¦.
It's also read in and parsed by coap_new_oscore_conf(3). Two ways in, same file, iconic.
Here's a lil detail that matters: this configuration file can be a configuration held in memory, and the formatting of that memory region is the same as that for a file β literally as if the file was mapped into memory. The coap_new_oscore_conf(3) function uses the memory version of the file. So same vibes, different delivery method π«.
The file itself is a set of keywords: you've got the keyword, the value of the keyword's encoding type, and the keyword value. One per line, comma separated. Like this π
keyword,encoding,value
Keywords are case sensitive β do not play with the casing, fr. If a line starts with a #, it's treated as a comment line and gets ignored. Empty lines are also valid and ignored. So you can absolutely sprinkle comments everywhere, main character energy π.
π The possible encodings (iykyk) π
asciiβ the value is encoded as a binary representation of the ascii string. This string can optionally be enclosed in".boolβ the textual string is eithertrueorfalse, and it's subsequently encoded as an integer number.hexβ the value is encoded as a binary representation of the hex string. This string can optionally be enclosed in".integerβ the value is encoded as an integer number.textβ the string value is mapped and then encoded as an integer number. This string can optionally be enclosed in". A subset of the Names fromhttps://www.iana.org/assignments/cose/cose.xhtml#algorithmsorhttps://www.iana.org/assignments/cose/cose.xhtml#elliptic-curvesare supported π
π₯ The valid keywords (aka the whole menu) π₯
master_secretβ (hexorascii) (Required) (No default) "RFC8613 Section 3.1. Security Context Definition". Master Secret. Variable length. Must be the same for both client and server. Same secret, both sides, no exceptions πmaster_saltβ (hexorascii) (Optional) (No default) "RFC8613 Section 3.1. Security Context Definition". Master Salt. Variable length. Must be the same for both client and server.id_contextβ (hexorascii) (Optional) (No default) "RFC8613 Section 3.1. Security Context Definition". ID Context. Variable length. Must be the same for both client and server.sender_idβ (hexorascii) (Required) (No default) "RFC8613 Section 3.1. Security Context Definition". Sender ID. This is the local application ID. Maximum length is determined by the AEAD Algorithm (typically 7 bytes).recipient_idβ (hexorascii) (Required for client, else Optional) (No default) "RFC8613 Section 3.1. Security Context Definition". Recipient ID. This is the remote peer application ID. Maximum length is determined by the AEAD Algorithm (typically 7 bytes). For servers, there can be zero or more (unique) recipient_ids. Additional recipient_ids can be added programmatically to the OSCORE configuration β seecoap_new_oscore_recipient(3). For clients, there should only be one recipient_id (only the first is used). So like, don't go stacking recipient_ids as a client, she's a one-recipient_id kind of client πreplay_windowβ (integer) (Optional) (Default is32) "RFC8613 Section 3.1. Security Context Definition". Recipient Replay Window (Server Only). Supported values are1-63.aead_algβ (integerortext) (Optional) (Default is10or"AES-CCM-16-64-128") "RFC8613 Section 3.1. Security Context Definition". AEAD Algorithm. Only the mandatory and a small subset of the algorithms are supported depending on the TLS library. So likeβ¦ it depends on your TLS library, babe π«Άhkdf_algβ (integerortext) (Optional) (Default is-10or"direct+HKDF-SHA-256") "RFC8613 Section 3.1. Security Context Definition". HDKF Algorithm. Only the mandatory and a small subset of the algorithms are supported depending on the TLS library. (Yes, the original says "HDKF" there β we keep it exactly as written, I don't make the rules π)rfc8613_b_1_2β (bool) (Optional) (Default istrue) "RFC8613 Appendix B.1.2. Replay Window". Enable server rebooting Replay Window.rfc8613_b_2β (bool) (Optional) (Default isfalse) "RFC8613 Appendix B.2. Security Context Derived Multiple Times". Enable Security Context protocol.ssn_freqβ (integer) (Optional) (Default is1) "RFC8613 Appendix B.1.1. Sender Sequence Number". Sender Sequence Number frequency non-volatile storage update rate. Has to be a positive number. Positive. Number. Do not test me β
π Diagnostic testing options π
These are for testing, bestie β not your everyday config π§
break_sender_keyβ (bool) (Optional) (Default isfalse) Enable random breaking of the derived sender key.break_recipient_keyβ (bool) (Optional) (Default isfalse) Enable random breaking of the derived recipient key.
π¦ EXAMPLE SERVER OSCORE CONFIGURATION FILE π¦
Like, here's a whole server config you can straight-up copy:
# Master Secret (same for both client and server)
master_secret,hex,"0102030405060708090a0b0c0d0e0f10"
# Master Salt (same for both client and server)
master_salt,hex,"9e7ca92223786340"
# Sender ID
sender_id,ascii,"server"
# Recipient ID
recipient_id,ascii,"client"
# Replay Window (usually 32)
replay_window,integer,32
# AEAD COSE Cipher Algorithm (usually 10)
aead_alg,integer,10
# HKDF COSE Algorithm (usually -10)
hkdf_alg,integer,-10
πΈ EXAMPLE CLIENT OSCORE CONFIGURATION FILE πΈ
And here's the client one β notice the sender/recipient IDs are swapped, that's the whole point babe π
# Master Secret (same for both client and server)
master_secret,hex,"0102030405060708090a0b0c0d0e0f10"
# Master Salt (same for both client and server)
master_salt,hex,"9e7ca92223786340"
# Sender ID (This is the client who is the Sender)
sender_id,ascii,"client"
# Recipient ID (It is the server that is remote)
recipient_id,ascii,"server"
# Replay Window (usually 32)
replay_window,integer,32
# AEAD COSE Cipher Algorithm (usually 10)
aead_alg,integer,10
# HKDF COSE Algorithm (usually -10)
hkdf_alg,integer,-10
π SEE ALSO π
Go give these a read, they're literally faves: coap-client(5), coap-server(5) and coap_new_oscore_conf(3).
π FURTHER INFORMATION π
See
"RFC8613: Object Security for Constrained RESTful Environments (OSCORE)"
for further information. That's the source of truth, go drink your water and read it π
π BUGS π
Found a bug? Please raise an issue on GitHub at https://github.com/obgm/libcoap/issues to report any bugs. And if you've got a fix? Please raise a Pull Request at https://github.com/obgm/libcoap/pulls for any fixes. Community slay π«Ά
π AUTHORS π
The libcoap project <libcoap-developers@lists.sourceforge.net>
K that's the whole page, you ate it π β¨
Sign-off vibes: this beauty is coap-oscore-conf 4.3.5, dated 08/24/2026 β and it's the COAP-OSCORE-CONF(5) page, go forth and OSCORE responsibly πππ
π¦ where this page comes from
- ubuntu stonking: libcoap3-bin 4.3.5-4ubuntu1 Β· BSD-2-Clause
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms