On Thu, 9 Oct 2025 at 19:58, Simo Sorce <[email protected]> wrote: > On Thu, 2025-10-09 at 19:20 +0530, tirumal reddy wrote: > > Thanks Simo for the review. Please see inline > > > > > > > 3) The use of AKP here really shows how AKP is not a great option > > > (IMHO), as it forces a distinction that makes little or no sense, given > > > there is no risk of confusion or misuse between direct agreement and > > > key wrap uses with the same keypair. I can see how some protocols may > > > want to use either/or with the same key depending on the other > > > circumstances (section 10). > > > > > > > > > The WG needs to discuss and decide whether to use AKP or OKP for this > purpose. > > > > The key trade-off seems to be between enforcing algorithm binding in the > key structure to reduce misuse and keeping flexibility to avoid layering > issues. If JWK starts enforcing operational policies (like “this key must > only be used for this algorithm”), it may interfere with higher layers > (such as application logic or key management) that should be making those > decisions. One possible balanced approach would be to continue using AKP, > but make the "alg" field optional when the key is used for key agreement. > > The problem is that once JWKs carry the algorithm the only option is > not whether or not alg is used, but whether or not multiple algorithm > should be considered equivalent and interchangeable for some mechanism, > and I believe that will not be a good compromise, which is why I > brought it up here. I do agree that the WG really need to think hard > whether it is proper to try to enforce policy mechanisms at the storage > format/information exchange level, or not (I think not). >
I suggested the above option to help resolve the WG discussion on whether to use AKP or OKP. The draft can be updated to list the respective pros/cons and allow implementations to make a choice. > > > > > > > > 4) I object to the characterization that forcing the use of SEED only > > > as a private key promotes interoperability, so I would drop that > > > preamble from the phrase that defines what the specification mandates > > > in this area (last paragraph of section 10). > > > > > > > > > No, it simplifies key transport and allows keying material to be > encrypted, exported/imported between HSMs without ambiguity. > > I understand that this is the position of some people in here, but I do > not subscribe to the idea that this is better for interoperability. > Because it prevents the exchange of keys from systems that do not > preserve the SEED, or can't extract it. > > (There is no consensus that NIST standards, as written today and until > they are amended, allow for the extraction of a SEED from a > cryptographic module, and therefore standardizing on SEED means there > may be interoperability issues with modules that allow only the "NIST > defined" secret key to be extracted and do not preserve the SEED.) > > I am not asking to remove the requirement to standardize on SEED only, > just that it is not incorrectly labeled as an interoperability choice, > because it is not. > The decision that it is for interoperability is already discussed and finalized in Section 4 of draft-ietf-cose-dilithium <https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/?utm_source=chatgpt.com>. This document aligns with that decision -Tiru > > Simo. > > -- > Simo Sorce > Distinguished Engineer > RHEL Crypto Team > Red Hat, Inc > >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
