[core] #222: RawPublicKey identifier

["core issue tracker" <[e-mail]>]

#222: RawPublicKey identifier

 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:

 http://tools.ietf.org/html/draft-farrell-decade-ni-03

 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
 RECOMMENDED.

 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.

-- 
----------------------------------+--------------------
 Reporter:  zach@…                |      Owner:  zach@…
     Type:  protocol enhancement  |     Status:  new
 Priority:  minor                 |  Milestone:
Component:  coap                  |    Version:
 Severity:  -                     |   Keywords:
----------------------------------+--------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/222>
core <http://tools.ietf.org/core/>