TLDR; I don't support adoption of an independent key draft. I think COSE HPKE has problems with keys that need to be fixed, and moving them to a separate document makes those problems worse / harder to fix.
I am strongly supportive of the work that has gone into the hpke key draft, and the examples and registry update requests should be included in COSE HPKE. It would be sufficient to generate examples for COSE HPKE where recipient keys signaled kem, kdf and aead, and only request registry changes necessary to support this. I don't see how you can use HPKE without knowing what a recipient supports, and I don't think it is smart to do that work in a separate document from where it is used. Inline: On Wed, Apr 12, 2023 at 2:55 AM Ilari Liusvaara <[email protected]> wrote: > On Tue, Apr 11, 2023 at 02:31:14PM -0500, Orie Steele wrote: > > On Tue, Apr 11, 2023 at 2:11 PM Ilari Liusvaara < > [email protected]> > > wrote: > > > > > I think things should be split as follows: > > > > > > - This document will be definition of HPKE kty for COSE and JOSE. > > > > > > > Seems like just adding the "kty" for HPKE to the HPKE COSE draft would be > > better. > > What would define how HPKE keys are represented in JWK (there apparently > are usecases even if there is no HPKE in JOSE)? > > There may be no JWE for HPKE, but that does not mean I should be forbidden from using a JWK with COSE HPKE. Daisuke has provided good use cases in his presentation, recipients want to use JWKs, because they are already using them for ECDH-ES. Example from the current key draft: { "kty": "EC", "kid": "01", "crv": "P-256", "alg": "HPKE-v1-Base", // new algorithm "hkc": { // parameters for the algorithm, that could have been done in the "alg" field above. "kem": 0x010, "kdfs": [0x001, 0x002, 0x003], "aeads": [0x001, 0x002] }, "x": "-eZXC6nV-xgthy8zZMCN8pcYSeE2XfWWqckA2fsxHPc", "y": "BGU5soLgsu_y7GN2I3EPUXS9EZ7Sw0qif-V70JtInFI" } > > > Especially since the "kty" and "hkc" are not useful by themselves. > > "hkc" is part of "other aspects". And I think the "kty" would be useful > on its own. > > How is the "kty" useful on its own? Can you use HPKE without a "kem id", or without a "kdf" ? Please describe in great detail how this would be useful for an HPKE sender: { "kty": "HPKE", // new kty, but it is for an algorithm that requires parameters to be useful "alg": "HPKE-v1-Base", // new algorithm, but which DHKEM is being used?.. which kdf and aead are supported? "x": "-eZXC6nV-xgthy8zZMCN8pcYSeE2XfWWqckA2fsxHPc", "y": "BGU5soLgsu_y7GN2I3EPUXS9EZ7Sw0qif-V70JtInFI" } > Then as pointed out by L. Lundblade in IETF116 discussion, there is no > precedent for anything like "hkc" in either JOSE or COSE. > > Yes!!!!!!..... Maybe we should pause and consider the "agility thread"... seriously. Perhaps JOSE and COSE have avoided exposing APIs that look like COSE HPKE, and its implied "hkc" counterpart for good reasons. I can be convinced by a good argument. It seems COSE HPKE violates assumptions around algorithms and keys for both JOSE and COSE users. If we are sure that the "new way" is better, let us have clear consensus and cheers for the revolution... or maybe let's not do it. I would start cheering if I saw consensus around what a long term HPKE recipient public key looks like... do we really need a separate document to do this? And that is not because there is no precedent for the issue: The very > same issue does pop up in ECDH, and seems the approach taken by both > COSE and JOSE is to not do anything about it in keys, but leave that > to the application profile. > > See my comment at the end about COSE Key and "alg", this is what JOSE says: > This section defines the specifics of key agreement with Elliptic > Curve Diffie-Hellman Ephemeral Static [RFC6090], in combination with > the Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A]. - https://www.rfc-editor.org/rfc/rfc7518.html#section-4.6 - https://www.rfc-editor.org/rfc/rfc8037#section-3.2 - https://www.rfc-editor.org/rfc/rfc7518#section-4.6.2 <https://www.rfc-editor.org/rfc/rfc7518#section-4.6.2> Because "ECDH-ES+A256KW" does not have the same kind of agility as HPKE. You cannot change the KDF in "ECDH-ES+A256KW", so using "alg" in the JWK is sufficient.... This appears to be a design choice that COSE HPKE disagrees with. If I see an HPKE envelope, and I am holding an HPKE key without "hkc", the situation is different.... It does not need to be this way, we could make HPKE ** less revolutionary **, and have the HPKE algorithm carry the "hkc" parameters, just like "ECDH-ES" does.... ... Or HPKE can stay revolutionary, and define a relation between an "alg" and supported parameters ("hkc").... Why do we think it is "good agility" to generate a recipient key that supports 3 KDF and 2 AEADs? Is it "good agility" if a sender gets to pick which of these parameters to use? Sure it's fine that the raw HPKE crypto allows this, but why register a JOSE / COSE algorithm that REQUIRES this?... What is COSE HPKE doing that is useful beyond what the CFRG RFC has done already? What is the COSE use case for forwarding the CRFG agility / optionality / complexity to application developers? Why move this complexity to a separate document, does it not affect the security considerations of COSE HPKE? > The "alg" (algorithm) parameter identifies the algorithm intended for > use with the key. - https://www.rfc-editor.org/rfc/rfc7517#section-4.4 Let's look at some cases side by side: // the old way... how HPKE would look if it worked like ECHD-ES { kty: EC, alg: HPKE-0x010-0x003-0x002 } // when I generated this key, this is the only thing I wanted to support. { alg: HPKE-0x010-0x003-0x002, enc: ... } // when sender encrypts to my key, they can see what parameters I use by reviewing the "alg" field. // the new way... how HPKE would look if it worked like the 2 drafts put together { alg: HPKE-v1-Base, "hkc": { "kem": 0x010, "kdfs": [0x001, 0x002, 0x003], "aeads": [0x001, 0x002] } } // when I generated this key, **these** are the only thingS I wanted to support. { alg: HPKE-v1-Base, sender_info } // when sender encrypts to my key, they can see **all** the different parameters I use by reviewing the "alg" field and **matching** to the parameters the sender supports that the recipient has announced. Using HPKE without "hkc" or "sender info" is not possible... *** unless the sender gets to decide and the recipient has to support everything *** (kitchen sink). If I see your key is: { "kty": "EC", "crv": "P-256", "alg": "HPKE-v1-Base", // ... guess my sender info "x": "-eZXC6nV-xgthy8zZMCN8pcYSeE2XfWWqckA2fsxHPc", "y": "BGU5soLgsu_y7GN2I3EPUXS9EZ7Sw0qif-V70JtInFI" } It is not enough for a sender to encrypt, the recipient has not sufficiently described their __supported algorithm parameters__, the sender does not know which parameters will be supported by the recipient... should the sender just use their preferred ones and hope for the best? This can be solved for in the "alg" or in "hkc", but it can't be ignored... AND it needs to line up with both the "envelope" and the "key". > > > - Any other aspects of keys in COSE (if any) go to COSE-HPKE document. > > > > > > > The main thing I see in the current hpke key draft is the "hkc" > parameter, > > which maps directly to the IANA registries for HPKE and is also directly > > coupled to the "alg" registry and "kty"... > > hence my comment about just putting them in the same document. > > The present document mixes the kty and other aspects a lot. I think > those should be separated. > > > I don't understand how you can use the key draft without reading HPKE > COSE > > at this point. > > That's because it goes much farther than just defining the kty. > > Exactly, and given how HPKE works, it is not useful to only define a "kty" for it, because such a key is not usable without the other parameters being known. We already have a "kty" for the DHKEMs, it is called "EC"... What we don't have, is a useful "alg" for PQKEMs, or DHKEMs and the examples we have seen all require parameters in addition to the algorithm... in order to work. making the algorithm alone... not sufficient to switch on... and... making HPKE's treatment of "alg", not a "standard COSE thing". > > And I also don't understand how to use the "alg" parameter in HPKE COSE, > > without defining where it goes in keys. > > Standard COSE rules apply. > > This is not true, "sender info" is a new thing, and it is being used as a substitute for an "alg" that normally would have carried this information, if standard COSE / JOSE were being used. Unlike 'kty: EC, alg: ECDH-ES+A256KW'... A standard COSE Key alg would not have the parameters necessary to allow COSE HPKE sender to encrypt to it.... *** unless, the sender gets to pick sender info, and the recipient has to support all the registry entries *** (kitchen sink). Again, if this "new way" is "better", great, we just need to explain how to signal support for the new way in COSE Key and JWK, and I will leave it alone : ) > > > - All work on other aspects of keys in JOSE is blocked on adopting > > > JOSE-HPKE, and would go to that document. > > > > > > > Yes, I agree that JOSE should not delay things, > > but it seems that defining JWK representation that supports the "alg", > > "kty" and "hpc" > > parameters in a way similar to COSE Key, is a reasonable place to stop. > > Here be dragons. The major problem is that "alg" depends on how > JOSE-HPKE works. Is this the first case of this for JOSE and COSE? """ When using a COSE key for this algorithm, the following checks are made: o The 'kty' field MUST be present, and it MUST be 'EC2' or 'OKP'. o If the 'alg' field is present, it MUST match the key agreement algorithm being used. o If the 'key_ops' field is present, it MUST include 'derive key' or 'derive bits' for the private key. o If the 'key_ops' field is present, it MUST be empty for the public key. """ - https://datatracker.ietf.org/doc/html/rfc8152#section-12.4.1 Does the key agreement algorithm really differ for JOSE and COSE? If key agreement works the same, what about the other parameters, kem, kdf, aead?... do they each work differently depending on if you use JOSE or COSE? Or are we just intentionally designing COSE HPKE (and possibly soon, HPKE KEY) so this is the case? > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
