[Anima] Pinning of raw public keys in Constrained Vouchers

[Michael Richardson <[e-mail]>]

I've been trying to improve the text to better explain pinning of registrar keys
(rather than certificates), in order to resolve
   https://github.com/anima-wg/constrained-voucher/issues/18

and also to remove as many bytes on the wire required to do constrained
enrollment, the question came up.  The registrar identity crosses
the wire three times!

1) the registrar sends it's identity (whether raw public key or
   certificate) during the DTLS or EDHOC handshake,

2) the pledge sends the registrar's identity in the voucher-request (signed),

3) then the MASA sends the registrar's identity in the voucher (signed).

Couldn't we send a hash of identity in (2) and (3), and to do this we need a
new element in the constrained voucher.  This I've given the mouthful name
of:  proximity-registrar-sha256-of-subject-public-key-info
and: pinned-sha256-of-subject-public-key-info
(knowing that the YANG->SID process will turn this into a small integer).

A sha256 hash is 32-bytes in size.
A 256-bit ECDSA key is about 32-bytes in size.
An equivalent 2048-bit RSA key is 256 bytes in size.
So the hash only wins if we use bigger ECDSA keys, or if we use RSA.
(okay, so there are a few bytes for the subject-public-key-info (SPKI) wrapping,
which also provides algorithm agility)

We could truncate the hash if we felt this was still secure enough
We could add the length of the thing (the RPK) being hashed if that would
help with pre-image attacks, but that's mostly already there in the SPKI
encoding, but I suppose an attacker might find a way to prepad with nonsense
DER.

Please help me decide if this is a useful thing to do.
If it's useful, is it useful enough to drop the pinned-domain-subject-key-info?

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-