Opened 10 years ago

Closed 10 years ago

#222 closed protocol enhancement (fixed)

RawPublicKey identifier

Reported by: zach@… Owned by: zach@…
Priority: minor Milestone:
Component: coap Version:
Severity: - Keywords:


During the IETF-83 CoRE meeting a slide was presented on how to close the RawPublicKey? identifier issue in the draft. Out of the three options presented (just use the public key, define it in the CoAP draft, define it in some other draft), there was room consensus to define this in a separate draft. Ari Keränen took an action point to work on this draft with other security people, which has been completed and published here:

This ticket proposes the following changes:

  1. Remove Appendix D
  2. Add the following text to Section 10.1.2 (contributed by Ari, thanks!):

Provisioning in RawPublicKey? Mode

The RawPublicKey? mode was designed to be easily provisioned in M2M
deployments. It is assumed that each device has an appropriate
asymmetric public key pair installed. An identifier is calculated
from the public key as described in Section 2 of [draft-ni]. All
implementations that support checking RawPublicKey? identities MUST
support at least the sha-256-120 mode (SHA-256 truncated to 120
bits). Implementations SHOULD support also longer length
identifiers and MAY support shorter lengths. Note that the shorter
lengths provide less security against attacks and their use is NOT

Depending on how identifiers are given to the system that verifies
them, support for URI, binary, and/or human-readable format
[draft-ni] needs to be implemented. All implementations SHOULD
support the binary mode and implementations that have a user
interface SHOULD also support the human-readable format.

During provisioning, the identifier of each node is collected, for
example by reading a barcode on the outside of the device or by
obtaining a pre-compiled list of the identifiers. These
identifiers are then installed in the corresponding end-point, for
example an M2M data collection server. The identifier is used for
two purposes, to associate the end-point with further device
information and to perform access control. During provisioning, an
access control list of identifiers the device may start DTLS
sessions with SHOULD also be installed.

Change History (2)

comment:1 Changed 10 years ago by zach@…

Done in r690.

comment:2 Changed 10 years ago by zach@…

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.