The reason being the key length. Right, and I also would like to re-parent my subkeys if I ever do that.
@jarkko why do you need to bringnover the subkeys?
@andrewg Less migration in one shot :-) I could create new ones if that is impossible but then I need to update e.g. my authentication key in a number of places.
@jarkko I think sequoia supports adoption of old subkeys, but I haven't tried it myself. Migration to new pgp keys is still very much WIP... 
@andrewg Yeah, so I'm also pro-actively worried about web of trust in this case, as unless I can migrate trust to a new ceritficate key, it is impossible to use it in future new subkeys e.g. for signing Git tags for Linux kernel.
@jarkko I'm currently working on a draft spec that does just this, but nobody has implemented it yet. If this would be of use to kernel developers, I'd be happy to mention it, to encourage the implementers... https://datatracker.ietf.org/doc/draft-ietf-openpgp-replacementkey/
IETF DatatrackerOpenPGP Key ReplacementThis document specifies a method in OpenPGP to suggest a replacement for an expired, revoked, or deprecated primary key.
@andrewg Thanks much appreciated! I will check this out, thank you. But might take a few weeks, but I put that to my unofficial employer agnostic backlog ;-)
I have one IETF implementation in progress that I should some day finish up for TPM2 bits:
https://datatracker.ietf.org/doc/draft-woodhouse-cert-best-practice/
I've started v8 of this but other stuff got in the way:
https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/
Not forgotten tho, sometimes things just take a bit of time :-)
I have one IETF implementation in progress that I should some day finish up for TPM2 bits:
https://datatracker.ietf.org/doc/draft-woodhouse-cert-best-practice/
I've started v8 of this but other stuff got in the way:
https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/
Not forgotten tho, sometimes things just take a bit of time :-)
IETF DatatrackerRecommendations for applications using X.509 client certificatesX.509 certificates are widely used for client authentication in many protocols, especially in conjunction with Transport Layer Security ([RFC5246]) and Datagram Transport Layer Security ([RFC6347]. There exist a multitude of forms in which certificates and especially their corresponding private keys may be stored or referenced. Applications have historically been massively inconsistent in which subset of these forms have been supported, and what knowledge is demanded of the user. This memo sets out best practice for applications in the interest of usability and consistency.
@andrewg @nwalfield And you really know how to pitch your software.
Usually it is like "look I made this better version of this tool with Rust" or something, and not pointing out the exact features that help to solve a particular problem (and more often than not you end up finding that the particular tool cannot resolve your problem).
This type doing right things right is rare today (unfortunately).
Usually it is like "look I made this better version of this tool with Rust" or something, and not pointing out the exact features that help to solve a particular problem (and more often than not you end up finding that the particular tool cannot resolve your problem).
This type doing right things right is rare today (unfortunately).