Encrypted fields

[miceiken]

This thread is dedicated to the discussion of the specification and implementation details of the encrypted fields feature. A working draft of the specification can be found in #8.

[miceiken]

Public Key

Looking at the reference implementation using PKCS#1 and PEM format for public keys exchange and identifier I think we might run into some issues with canonicalization, particularly for key fingerprinting/identifier. After some rudimentary testing it seems there are some variations in implementations of PEM formatting that can easily cause headaches.

One option is to generate the key identifier using the DER format (binary) rather then PEM (ASCII), which seemingly gives consistent results across the board.

Suggestion: PKCS#1 generated RSA keys encoded in the PEM format. Key identifier is deduced by hashing the DER formatted public key using SHA256.

Example: RSA Private and Public Key generation using OpenSSL

openssl genrsa -des3 -out private.pem 2048
openssl rsa -in private.pem -outform PEM -pubout -out public.pem
openssl rsa -in public.pem -pubin

Output: RSA Public Key in PEM format

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwuMCKOdptWX0DBKKbHDw
XTZSiJxq3pdk97p6OUO9Rwp39RE/YYw0UDYryMbMO8Bhs5CXaXNvQHop2ljCoKtc
5o/njuWM2Y+SZhi8exG2dK1a82MCJBM9ds79UaV98R+ZgNEUVUtYuww4tdOCYWuL
PYaLo/cueEh6/fJEcirLr53S7EIY3uUOhvCo7HcGBrIvho6kEDxmsi08V5jeBNXM
QtI4Fc0mhy+ptHkBT4m6VMZxIo7dpH4RtWXpOR8PBeDbOQRMku43af0RQMpzj/nq
ZHpB6O1lIUHGaNWCEF7NE6+V1ELFS/BFlb/k1zJrou3EBoc5IZizJtFx3JLaax6v
+wIDAQAB
-----END PUBLIC KEY-----

Example: Output Public Key Identifier using OpenSSL

openssl rsa -in public.pem -pubin -outform der | openssl dgst -sha256

Output: Public Key Identifier

72ed9c094aeaffa12c467c431dcc22d678d6363ee2d76c79e3f28c67f709243b

What are your thoughts on this?

[miceiken]

.NET fiddle: https://dotnetfiddle.net/Ka6tK1

[tw-martijn]

I think we at Refa[[ did not consider using actual key fingerprints as identifiers when we wrote the first draft. Instead thinking that an arbitrary key ID would be supplied together with the public key. Could be something like partner-refapp-2021-01-12 for a key supplied by a partner integration like us, and ats-recruitee-001 for the public key send along with the invitation. Feels like we are working with a small enough problem space that key ID conflicts are extremely unlikely to occur.

The only reason the proof-of-concept Node.js code is using a hash as identifier is because I wanted something that would be different on every run for testing purposes.

As you say, if we do want to go with a hash as fingerprint, we should document exactly what needs to be hashed. The (X.509) DER version of the public key makes sense. Even if non-binary versions are used and stored elsewhere, it is generally not very hard to convert to DER.

How do we weigh the complexity of documenting canonicalisation and hashing VS the risk of arbitrary strings matching sometime in the future?

[miceiken]

Fair point. We can use arbitrary strings as keyId and avoid the complexity :)