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 <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
