> Thanks for doing this research, Brian. We only support ephemeral- > static mode, so your findings are quite pertinent. I therefore propose > that we further revise the text as follows: > > Applications MUST specify what values should be used in the "apu" and > "apv" parameters.
What does this mean? Isn't a JOSE sender "specifying what value should be used" by actually including an "apu" field in a message? Is this supposed to mean a sender MUST tell recipients (out-of-band) what will be used so recipients can confirm the "apu" value is correct? MUST recipients do this (app-specific) confirmation? Are "Applications" in this context something like OpenID Connect (OIDC)? If Concat KDF really is app-specific we shouldn't define "ECDH-ES" in JWA but leave it to, say, OIDC to define "ECDH-ES/OIDC" along with a definition of what actually goes into PartUInfo etc and any parameters needed to convey that. A "MUST" followed by a "should" in the same sentence makes little sense. > Applications wishing to conform to [NIST.800-56A] If we specify the use of Concat KDF (defined in NIST.800-56A) then surely this implies you have to conform to NIST.800-56A. We can't take a NIST KDF, keep the name, but not keep the other constraints. > need to provide values that meet the requirements of that document, > e.g., by using values that identify the sender and recipient. > Alternatively, applications MAY conduct key derivation in a manner > similar to [RFC2631]: In that case, the "apu" field MAY either be > omitted or represent a random 512-bit value (analogous to PartyAInfo in > Ephemeral-Static mode in [RFC2631]) and the "apv" field should not be > present. -- James Manger _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
