I agree with Hannes : ) I will note that AKP is the only key type that commits to the algorithm being used with the key when computing the thumbprint. I'm biased, I think AKP is the best choice for keys that are meant to be used with only one algorithm, which should be all keys that are created in accordance with:
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf or similar. ``` The estimated time period during which data protected by a specific cryptographic algorithm (and key size) remains secure is called the algorithm security lifetime. During this time, the algorithm may be used to both apply cryptographic protection (e.g., encrypt data) and process the protected information (e.g., decrypt data), although the period allowed for applying protection (the originator-usage period) could be shorter than the algorithm security lifetime (see Figure 2) ... In general, a single key shall be used for only one purpose (e.g., encryption, integrity authentication, key wrapping, random bit generation, or digital signatures). ``` AKP is meant to make it hard for keys to have qualities that can lead to mistakes: 1. Algorithm is required. 2. Private information and Public information are minimized to "pub" and "priv" (No "x", "d", "n", "q", etc...) 3. Thumbprints (used to uniquely name keys) take algorithms into account, so you can find all references to a key that use a specific algorithm, when thumbprints are stored in or alongside the key. That said, there could be compelling reasons to allow for flexibility in cases where compatibility or algorithmic agility is more important than reducing risk of misuse. Looking forward to seeing a call on this topic. Regards, OS (as an author that worked on AKP) On Tue, Sep 16, 2025 at 9:50 AM Tschofenig, Hannes < [email protected]> wrote: > Hi all, > > > > I have read the mailing list discussion around key types in the PQC KEM > draft (draft-ietf-jose-pqc-kem). This might seem like an unexciting detail. > After all, who really cares about the name of the structure in which the > key is embedded? Yet, quite to my surprise, it has turned out that there > are multiple views on the subject. > > > > From what I can see, there is no obvious “clear winner” among the three > candidates (“OKP”, “AKP”, and a new key type). In fact, it is striking how > many different key types we already have in the JOSE ecosystem. > > > > The good news, however, is that whichever option we select, the > implementation effort is minimal. > > > > I would request the chairs to make a consensus call so that we can close > this issue and move on with the draft. > > > > Ciao > > Hannes > > > > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
