On Tue, 29 Jul 2025 at 00:11, Neil Madden <[email protected]> wrote:
> On 28 Jul 2025, at 19:07, Ilari Liusvaara <[email protected]> > wrote: > > > > On Mon, Jul 28, 2025 at 06:13:51PM +0200, Filip Skokan wrote: > >> > >> As far as the other questions from the presentation to the working > group go > >> I believe this is fair summary > >> > >> - Why not Use AKP Slide - Use of AKP doesn't introduce ambiguity, it > >> removes it. Not being able to use the same JWK for both modes when > using > >> AKP is a problem that doesn't need solving. > > > > It is a operational problem that needs solving. > > I really don’t see why this is a problem. If you really need the same key > to be used for both algorithm variants then simply publish it twice in the > key set, once with each “alg”. This duplication increases operational complexity: - Key rotation and lifecycle management (e.g., revocation) become more complex when the same key material is duplicated - "AKP" would require different "kid" values for each duplicated key Let's weigh these trade-offs before switching to "AKP". -Tiru > > > > One way to solve it > > would be to remove the Direct Key Agreement algorithms, since at least > > Key Agreement with Key Wrapping is at worst a size penalty, instead of > > not working at all. > > I have some sympathy for removing Direct Key Agreement. (That said, if we > ever want to bring back HPKE’s AuthKEMs, this seems easier to get right in > direct mode). > > > Then one could convert the algorithm into Key Encryption algorithm so > > that compact encoding does not need to double-base64url the already > > large KEM ciphertext in compact encoding. > > > > - 1088 bytes double encoded -> 1935 bytes. > > - 1088+40 bytes encoded -> 1504 bytes. > > — Neil > _______________________________________________ > 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]
