Elliptic curves

[BillBennett]

CoAP says "The curve secp256r1 MUST be supported" but also "The type and length of the raw public key depends on the cipher suite used". I think that means that it doesn't prohibit other curves.

If that's the case then there needs to be a "curve name" resource in the security object.

[jvermillard]

+1 this is confusing
maybe using the ANSI X.9.63 format could help to store keys in RPK mode

[BillBennett]

OpenSSL (and I assume other tools?) generate DER-encoded keys in the RFC5915 structure.

Filesize is 121 bytes for secp256r1, which consists of the curve OID, private key and public key.

Given that the keys themselves are already 96 bytes it's a 26% overhead, but I think it would make key-generation a lot simpler and resource 3 (Public Key or Identity) would not be needed for RPK mode. It also allows for compression if someone wants to use it (size drops to 89 bytes), and future extensibility.

[hannestschofenig]

The raw public key structure, namely SubjectPublicKeyInfo, does not only include the raw key but also relevant parameters to the describe the public key crypto system. Here is the link to the document: https://tools.ietf.org/html/rfc7250

I do, however, agree that the text in Appendix E.1.1.2, see below, is incomplete and incorrect. It is incomplete since it does not specify the actual encoding and it is incorrect with regards to the size indication since the size depends on ASN.1 encoding of the parameters.

This needs to be fixed for LWM2M version 1.0.

---

E.1.1.2 Raw-Public Key (RPK) Mode
The raw-public key mode requires a public key and a private key of the appropriate type and length for the Cipher Suite used. These keys are carried as a sequence of binary bytes with the public key stored in the Public Key or Identity Resource, and the private key stored in the Secret Key Resource. The default RPK Cipher Suites defines in this specification use a 256-bit ECC key. Thus the Certificate Resource would contain a 32 byte public key and the Secret Key Resource a 32 byte private key.

[hannestschofenig]

In an attempt to write a chance request I noticed two problems:

• The specification doesn't mandate a specific type of elliptic curve. This aspect could be postponed to LWM2M version 1.1 when we align the specification with the DTLS / TLS IoT profile (see https://tools.ietf.org/html/rfc7925)
• RFC 7250 describes the encoding of the public key but not the private key. Normally, the private key is not sent over the wire but with the LWM2M bootstrapping specification it is. Hence, one also has to think about the appropriate encoding of the private key. A possible candidate would be RFC 5958.

Note that this issue is also applicable to the encoding of the private key for the certificate mode. Furthermore, there is also not format defined for the encoding of the certificate. PKCS #12 is a possible candidate.

[ThGarnier]

Addressed by CR101 : includedin Oct16 TS => to be closed

[Megan-OMA]

Issue closed per Thierry's comment that is addresses in October 2016 TS