Hi Filip, I just replied to the other thread:
https://mailarchive.ietf.org/arch/msg/cose/dlKWs1H9r282oI2OvhYz3NIz30A/ I won't repeat all the arguments there, but I will share my view of how to approach the problem. We should seek representations that minimize information, while complying with the requirements of the protocols. kty is required for historical reasons. JOSE: alg is mandatory in messages, optional in keys. COSE: alg is optional in messages, optional in keys. Each new key type defines which key parameters are mandatory. Regarding: kty, alg, and pub It's my understanding that this is the minimal public key restricted to a single algorithm in JOSE and COSE. It's possible the algorithm and public key are mismatched, and verification will always fail. If no algorithm is specified, it's possible the signature algorithm is chosen by the attacker, it's weird to have the verification algorithm come from the signature and not the key, but that's historical for JOSE and COSE at this point. There is text that exists that states that verifiers have to accept the verification algorithm before running it, at best, this just means they can accept different signature or key agreement schemes for the same public key, when no algorithm is specified in the key. This has led to discovering supported algorithms outside / separate from discovering supported keys, an issuer / recipient can advertise that they support multiple algorithms, and then use the same key restricted to each algorithm, or use a single key with no algorithm restriction. I consider the safest approach to be restricting a key to a single algorithm, and never using the key for anything other than that algorithm... if you need a new algorithm, generate a new key. There are also key / algorithm fingerprinting issues... for JWK / COSE Key, the minimum mandatory parameters for the public key need to be in the fingerprint... for keys other than AKP, this means the fingerprint is not commiting to the algorithm, only the mandatory key parameters and key type. Regarding: kty, alg, seed, pub (priv missing) It's my understanding that this is the minimal private key with the requirement that the public key also be present. There would be a risk that the pub was not expanded from seed here. There is also a risk that the algorithm is not compatible with the pub. Regarding: kty, alg, seed How the seed is expanded would be algorithm specific. The seed might not be large enough for certain algorithms (see X-Wing). You can't create a fingerprint for this, without expanding the public key. Regards, OS On Thu, Mar 27, 2025 at 11:44 AM Filip Skokan <[email protected]> wrote: > Hello Orie, > > (adding JOSE cc) > > I am supportive of defining AKP semantics for seed vs private key forms, > but I would like to know whether to align fully with LAMPS in terms of > expanded, seed, or both is necessary. It is entirely possible that's a > discussion that happened and I am not aware of it, in which case I > apologize. I can imagine a JWK representation restricted to just the > following combinations would work just fine as well and would lead to less > edge cases to be handled by users and libraries > > - kty, alg, and seed (pub missing, priv missing; not required given a > seed is present, no consistency checks required) > - kty, alg, and pub > - kty, alg, priv and pub (seed missing) > > Interested in what you think? Are we just patching an almost done piece of > work at this moment? Or is there a moment to step back and come up with a > clean setup given the LAMPS outcome. > > S pozdravem, > *Filip Skokan* > > > On Tue, 25 Mar 2025 at 17:34, Orie <[email protected]> wrote: > >> Hi, >> >> https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/16 >> >> As discussed at IETF 122, I have raised this pull request to track the >> changes anticipated in the LAMPs WG. >> >> As I was not able to attend either session, I would greatly appreciate >> reviews / comments, to ensure this PR is heading in the right direction. >> >> I've made some adjustments to the parameter names, and added some >> normative guidance text, to ensure that the allowance of multiple key >> parameters for private information classes is not an invitation for future >> registrations to follow this pattern. >> >> I'm including our ADs since this document is already in AD Evaluation, >> and the draft-ietf-lamps-dilithium-certificates document authors for >> visibility. >> >> Regards, >> >> OS >> >> _______________________________________________ >> COSE 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]
