On Tue, Jan 09, 2024 at 11:59:23AM -0600, Orie Steele wrote:
> Illari's recommendations make sense to me.
> 
> > * JWE per-recipient headers SHALL contain BASE64URL encoding of the
>   HPKE enc output as "epk" parameter.
> 
> seems like a new header param here might be better.

Yeah, might be better to create new one.


> > The "epk" (ephemeral public key) value created by the originator for
>    the use in key agreement algorithms.  This key is represented as a
>    JSON Web Key [JWK] public key value.  It MUST contain only public key
>    parameters and SHOULD contain only the minimum JWK parameters
>    necessary to represent the key; other JWK parameters included can be
>    checked for consistency and honored, or they can be ignored.  This
>    Header Parameter MUST be present and MUST be understood and processed
>    by implementations when these algorithms are used.
> 
> - https://www.rfc-editor.org/rfc/rfc7518.html#section-4.6.1.1

That is only in context of ECDH-ES. Note that is the JWA RFC, not JWE
RFC.

Whereas COSE globally defines "eph" to be cose_key.


> This is related to the comments I have made a few times about wrapping
> HPKE's enc as a "kind of key",
> 
> The requirements for JWK and COSE key are trivial, and we could easily make
> "encapsulated keys", valid "JWK or COSE Key".
> 
> If we reuse the "epk" param, I suggest we do that... otherwise we should
> register a new param.
> 
> strawman JWK for HPKE encapsulated key:
> 
> {
>   "kty" : "oct", // required (oct is usually used for symmetric, not sure
> if this is legal ... but can't use EC or OKP because HPKE output is opaque.)
>   "k"   : "FdFYFzERwC2uC...bt-KWRBICVQ" // raw output of HPKE (k is a
> Private Parameter, but here it transports a Public encap key)
>   // per the SHOULD, other optional stuff is allowed here...
> }

That is actually exactly the hack I used a while back. And I don't think
it is a good idea.


> If we can't figure out how to make "encap" output serialized as JWK COSE
> Key, we should register new headers, not abuse existing ones.

COSE-HPKE already has a new header for it ("enc"). Unfortunately, that
name collides with global JWE header.

So either COSE-HPKE header needs to be renamed, or JOSE-HPKE needs to
pick a different name for it.

 
> I agree if we have to sacrifice, we should cut on the JWE side.

Cutting some corners with JWE simplifies this stuff a lot (otherwise
one would have to do stuff like mess with HPKE key exporters).




-Ilari

_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to