1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
//! A CoAP security tool for embedded devices, supporting OSCORE/EDHOC and managing credentials.
//!
//! This crate is under active development; breaking changes will be made as necessary. It
//! currently only handles the server side of CoAP exchanges. At runtime, there is more copying of
//! messages than is generally preferred; those result from limitations of underlying tools and are
//! being addressed there.
//!
//! This crate builds on several components technically and logically:
//!
//! * [libOSCORE](https://gitlab.com/oscore/liboscore/) provides the OSCORE implementation.
//! * [Lakers](https://github.com/openwsn-berkeley/lakers) provides the EDHOC implementation.
//! * The combined handling of OSCORE and EDHOC was originally explored in [EDF's CoAP/ACE-OAuth
//! proof-of-concept firmware](https://gitlab.com/oscore/coap-ace-poc-firmware/). Since this
//! crate matured, that firmware now uses coapcore.
//! * The crate is maintained as part of [Ariel OS](https://ariel-os.org/), whose CoAP stack
//! integrates it and [manages server access
//! policies](https://ariel-os.github.io/ariel-os/dev/docs/book/tooling/coap.html#server-access-policy).
//! Nothing in this crate depends on Ariel OS, but some examples may refer to it.
//!
//! # Usage
//!
//! This crate is mainly used with a CoAP stack (something that takes a [`coap_handler::Handler`])
//! and a CoAP server application (an implementation of a [`coap_handler::Handler`]). Rather than
//! passing the handler directly to the stack (which then only applies security mechanisms built
//! into that concrete stack, if any), a [`OscoreEdhocHandler`] is
//! [created][OscoreEdhocHandler::new] from the application, and passed into the stack.
//!
//! The arguments passed to the [`OscoreEdhocHandler`] at construction guide its behavior.
//!
//! # Logging
//!
//! Extensive logging is available in this crate through [`defmt_or_log`], depending on features
//! enabled.
//!
//! Errors from CoAP are currently logged through its [`Debug2Format`](defmt_or_log::Debug2Format)
//! facility, representing a compromise between development and runtime complexity. Should
//! benchmarks show this to be a significant factor in code size in applications that need error
//! handling, more fine grained control can be implemented (eg. offering an option to make
//! [`Debug2Format`](defmt_or_log::Debug2Format) merely print the type name or even make it empty).
//!
//! This crate mainly logs on the trace, debug and error level; the latter provides details when an
//! error is sent over the network and the details are not visible to the peer.
//!
//! See the book for [how defmt is configured in
//! Ariel OS](https://ariel-os.github.io/ariel-os/dev/docs/book/tooling/defmt.html); outside of
//! that, regular [`defmt_or_log`] practica applies.
//!
//! **Warning**: At the Debug level, this module may show cryptographic key material. This will be
//! revised once all components have been interop-tested.
//!
//! # Caveats
//!
//! Currently, this has hidden dependencies on a particular implementation of the [`coap_message`]
//! provided (it needs to be a [`coap_message_implementations::inmemory_write::Message`]) by the
//! stack. There are plans for removing this limitation by integrating deeper with libOSCORE.
pub use GeneralClaims;
// Might warrant a standalone crate at some point
//
// This is pub only to make the doctests run (but the crate's pub-ness needs a major overhaul
// anyway)
pub use *;
pub use ;