If we assume AKP, and there is a desire to restrict a key to only integrated encryption, then the algorithm identifiers would need to be updated.
I can buy the security argument that it should be possible to restrict a key to only integrated encryption... Especially because with key encryption a weaker recipient could be attacked leading to disclosure. Having a way to distinguish the supported algorithms also fits with the spirit of fully specified algorithms. Regards, OS On Wed, Oct 22, 2025, 1:09 AM tirumal reddy <[email protected]> wrote: > I am good to proceed with defining a new key type for PQC KEMs and to keep > the "alg" parameter optional. Implementations that require strict algorithm > binding can mandate the presence of "alg". The "alg" field can be omitted > when the same key structure is reused across different modes, such as > direct encryption and key wrap similar to the way "alg" is not specified > for the existing OKP key type. > > Cheers, > -Tiru > > On Wed, 22 Oct 2025 at 03:04, Brian Campbell <bcampbell= > [email protected]> wrote: > >> Apologies, the beginning of the text in the parenthetical of that last >> sentence should have said "I'm *not* totally convinced myself" >> >> On Tue, Oct 21, 2025 at 1:34 PM Brian Campbell < >> [email protected]> wrote: >> >>> Agree with much of Orie's perspective here. >>> >>> Please do not attempt to redefine AKP. >>> >>> If consensus is that AKP isn't right for keys for PQ KEMs (I'm >>> totally convinced myself but I do definitely understand some of the >>> rationale), then new key type(s) are the appropriate way forward. >>> >>> On Sat, Oct 11, 2025 at 7:32 AM Orie <[email protected]> wrote: >>> >>>> I left comments on https://github.com/tireddy2/PQC_JOSE_COSE/pull/19 >>>> >>>> I will repeat them here for the list. >>>> >>>> Do not update the definition of AKP. >>>> >>>> Make a new key type if you want to have keys that have a different set >>>> of security properties (such as being explicitly used with multiple >>>> algorithms). >>>> >>>> If you want to go this route, I would lean into the idea that you can't >>>> actually enforce any algorithm checking at the key side, and just say that >>>> the attacker controlling the algorithm in the message is not a concern for >>>> kems. >>>> (I don't agree with this, but that's what the argument appears to be to >>>> me, please correct me if I am wrong). >>>> >>>> In JOSE and COSE, the algorithm on security objects is controlled by >>>> the attacker. >>>> Without requiring the algorithm to be on the key, you will need to "try >>>> it out" to see if it works. >>>> As soon as you do that, you are doing work for the attacker... The >>>> system may still fail closed, but you've already done more work than you >>>> needed to. >>>> >>>> It's easy to make a new key type, if the WG thinks a key type that can >>>> explicitly be used with many algorithms is a good thing, make one, that way >>>> people will know what they are getting when they see that key type. >>>> >>>> Regards, >>>> >>>> OS >>>> >>>> >>>> >>>> On Sat, Oct 11, 2025 at 8:09 AM Neil Madden <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> > On 11 Oct 2025, at 13:24, Ilari Liusvaara <[email protected]> >>>>> wrote: >>>>> > >>>>> > On Sat, Oct 11, 2025 at 10:29:59AM +0100, Neil Madden wrote: >>>>> >> >>>>> https://neilmadden.blog/2018/09/30/key-driven-cryptographic-agility/ >>>>> > >>>>> > AKP is incompatible with key driven cryptographic agility. >>>>> > >>>>> > The idea of key driven cryptographic agility is to specify some >>>>> > cryptographic service (e.g., signature, mac, KEM) at protocol level >>>>> and >>>>> > then have key specify how exactly that is implemented. And since this >>>>> > is polymorphic by definition, KDCA is also incompatible with fully >>>>> > specified algorithms. >>>>> >>>>> None of these things is true. >>>>> >>>>> — 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] >>>> >>> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.*_______________________________________________ >> 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]
