L29Ah16:49:08]<vanitasvitae> As a consequence I'd need something along the lines of : Account Identity Key owns (Device Primary Key owns Device Encryption Subkey and Device Signing Subkey)
why do you need separate primary/encryption/signing keys?
tim> However, currently virtually no OpenPGP implementation supports subkeys of subkeys.
> See https://gitlab.com/sequoia-pgp/weird-keys#results (cert-subkeys)
yeah that's what I meant when I told you that based on library economy X.509 would probably be the better choice
vanitasvitaeL29Ah: not every algorithm is capable of signing AND encryption. Therefore OpenPGP can use a signing capable primary key which owns an encryption subkey.
vanitasvitaeBut X.509 is another giant spec :(
L29Ahcan't you just limit yourself to those that can?
L29Ahthese days asymmetric crypto boils down to old-school rsa and dandy ed25519 anyway
vanitasvitaeIn theory you could limit yourself to those, but thats lame :P
vanitasvitaeAlso ed25519 is also just signing right? (EdDSA)
L29Ahyeah, seems like ed25519 keys are only usable for signing or ECDH, not for non-interactive message encryption
dequbedEd25519 is specifically an implementation of the EdDSA signature scheme. But you can absolutely use plain Curve25519 keys to do non-interactive message crypto. I don't think opengpg does or ever will implement that however.
dequbedBut last I checked there was talk about implementing X25519 which is the key agreement scheme based on the same curve.