RPK support for gnutls binding

[boaks]

I wanted to test the support for RPK. With the tinydtls-binding the -M works pretty simple. But with the gnutls binding I'm struggling.

coap-client-gnutls: option requires an argument -- 'h'
coap-client-gnutls v4.3.5 -- a small CoAP implementation
Copyright (C) 2010-2024 Olaf Bergmann <[email protected]> and others

Build: v4.3.5-29-g72190a88
TLS Library: GnuTLS - runtime 3.7.3, libcoap built for 3.7.3

Test using x509:

coap-client-gnutls -v 6 -m POST -e 'test 1234 50%25' -t 0 -c client.pem -j clientPrivateKey.pem coaps://localhost/devices
v:1 t:CON c:POST i:f795 {} [ Uri-Host:localhost, Uri-Path:devices, Content-Format:text/plain ] :: 'test 1234 50%'
Feb 13 12:21:31.033 INFO CN 'RPK' presented by server (Certificate)
Feb 13 12:21:31.035 WARN ***127.0.0.1:46622 <-> 127.0.0.1:5684 DTLS: Alert '42': Certificate is bad

(Works, the server just denies the handshake because the client certificate has not been added.)

coap-client-gnutls -v 6 -m POST -e 'test 1234 50%25' -t 0 -M clientPrivateKey.pem coaps://localhost/devices
Feb 13 12:23:21.136 WARN *** setup_pki: (D)TLS: RPK_BUF: Client Certificate configure failure
Feb 13 12:23:21.136 WARN setup_pki_credentials: 'Insufficient credentials for that request.'
Feb 13 12:23:21.136 WARN setup_client_ssl_session: 'Insufficient credentials for that request.'
Feb 13 12:23:21.136 ERR  cannot send CoAP pdu
v:1 t:CON c:POST i:03b1 {} [ Uri-Host:localhost, Uri-Path:devices, Content-Format:text/plain ] :: 'test 1234 50%'

fails. I also fails, if I add -c client.pem (same error message).

The used private key is the client demo key of Eclipse/Californium:

-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQg59PuAri3l+8cAbNL
bFFBAwd/h0cESnSD3iZSGyrr7xGhRANCAARDFg7n8zmJ7r7dA85oDLkwPoKQUgtn
Ahvas4EJf8RY9qhxfUf57KdSdoQRuarF43qucj+kfX2Pg+2x6B8cuvPN
-----END PRIVATE KEY-----

According ASN.1 decoder, that's:

SEQUENCE (3 elem)
  INTEGER 0
  SEQUENCE (2 elem)
    OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key type)
    OBJECT IDENTIFIER 1.2.840.10045.3.1.7 prime256v1 (ANSI X9.62 named elliptic curve)
  OCTET STRING (109 byte) 306B0201010420E7D3EE02B8B797EF1C01B34B6C514103077F8747044A7483DE26521…
    SEQUENCE (3 elem)
      INTEGER 1
      OCTET STRING (32 byte) E7D3EE02B8B797EF1C01B34B6C514103077F8747044A7483DE26521B2AEBEF11
      [1] (1 elem)
        BIT STRING (520 bit) 0000010001000011000101100000111011100111111100110011100110001001111011…

Any idea, what's wrong?
Do I need the private key in an other format?
If so, would it be possible to get a "working" test key to test it with that?

(With tinydtls binding the private key works.

coap-client-tinydtls -v 6 -m POST -e 'test 1234 50%25' -t 0 -M clientPrivateKey.pem coaps://localhost/devices
v:1 t:CON c:POST i:4c0a {} [ Uri-Host:localhost, Uri-Path:devices, Content-Format:text/plain ] :: 'test 1234 50%'
Feb 13 12:28:11.186 INFO CN 'RPK' presented by server (Certificate)
v:1 t:ACK c:2.04 i:4c0a {} [ ]

)

[mrdeep1]

Looks like there is a decoding issue when trying to find the Public Key component.

The current GnuTLS code is expecting to see a .pem file starting with -----BEGIN EC PRIVATE KEY-----.

I will look into why libcoap/gnutls does not support your format.

[boaks]

The current GnuTLS code is expecting to see a .pem file starting with -----BEGIN EC PRIVATE KEY-----.

Curios, that this file without EC is accepted for x509.

[mrdeep1]

Interesting. I will look further into this, but it is possible that x509 was happy with the .pem for PKI, but not RPK.

[boaks]

OK.

Works, when keys are generated using

openssl ecparam -genkey -name prime256v1 -noout -out privkey.pem

(But openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out privkey.pem doesn't.)

-----BEGIN EC PRIVATE KEY-----
MHcCAQEEICsDN3q0p60WI44qzG9F3n7xBftk4q7LyRNbnoEBriYyoAoGCCqGSM49
AwEHoUQDQgAEuLtwGEbatYi3XBxU2hjNLpMW6yaTCVhB4gn79VPzkypI50EWrRDO
G/tQTKu1HGJgOMB/sryL4l5Zp07kYtrPkQ==
-----END EC PRIVATE KEY-----

SEQUENCE (4 elem)
  INTEGER 1
  OCTET STRING (32 byte) 2B03377AB4A7AD16238E2ACC6F45DE7EF105FB64E2AECBC9135B9E8101AE2632
  [0] (1 elem)
    OBJECT IDENTIFIER 1.2.840.10045.3.1.7 prime256v1 (ANSI X9.62 named elliptic curve)
  [1] (1 elem)
    BIT STRING (520 bit) 0000010010111000101110110111000000011000010001101101101010110101100010…

From my side, we can close it.

[mrdeep1]

Thanks for confirming that it works with another version of the RPK Certificate. I would like to try to get GnuTLS to handle your initial certificate though, but that will need some debugging / testing.