I raised a new PR https://github.com/tireddy2/PQC_JOSE_COSE/pull/20 to address the issue.
Cheers, -Tiru On Wed, 22 Oct 2025 at 21:37, Orie <[email protected]> wrote: > 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]
