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). > > > > 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. Simo. -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
