Orie is correct when he writes:
> It seems ok to know that you need process parameters differently based on the
> algorithm that is chosen.
I suspect that will come into play for HPKE.
This is completely parallel to “kty” in JWK and COSE_Key, where the
interpretation of the key parameters depends upon the key type.
-- Mike
________________________________
From: [email protected] <[email protected]> on behalf of Ilari
Liusvaara <[email protected]>
Sent: Thursday, June 20, 2024 9:29:38 AM
To: JOSE WG <[email protected]>
Subject: [jose] Re: [EXTERNAL] Re: HPKE and diminishing returns
On Thu, Jun 20, 2024 at 10:25:28AM -0500, Orie Steele wrote:
>
> On Thu, Jun 20, 2024 at 9:03 AM tirumal reddy <[email protected]> wrote:
>
> >
> > This complication can be avoided by defining {alg:
> > "HPKE-Base-P256-SHA256", enc: "A128"}.
> >
>
> Yes, and this is why we are coordinating with COSE, because we want to
> align on this sort of thing.
I would not want to align on this, because it would make COSE part much
more complicated (anything is more complicated than what COSE part is
currently doing!).
> > I think you mean a) Direct Key Agreement b) Key Agreement with Key
> > Wrapping.
> >
>
> Just to clarify the current source of this confusion.
> Both JOSE and COSE drafts use "HPKE-Base-P256-SHA256-A128GCM" for the case
> where you are logically doing this:
>
> alg: HPKE-Base-P256-SHA256-A128KW, enc: A128GCM ( 2 layer / indirect )
>
> alg: HPKE-Base-P256-SHA256, enc: A128GCM (1 layer / "integrated" )
>
> The hope is that by coordinating between JOSE and COSE, we pick algorithms
> that align, and we use them in headers and keys in a consistent way.
That is not what the COSE draft is doing. What the COSE draft is doing
would essentially be:
1) alg: HPKE-Base-P256-SHA256-A128GCM, enc: A128GCM
2) enc: HPKE-Base-P256-SHA256-A128GCM, no alg!
The second is very illegal in JWE (zero recipients and asymmetric enc),
but allowed in COSE.
(It is actually not trivial that the first one is allowed in COSE, but
ultimately it turns out all assumptions do line up).
> So far, both groups have been saying "HPKE-Base-P256-SHA256-A128GCM" works
> for both cases.... which seems to have confused people in both working
> groups.
HPKE-Base-P256-SHA256-A128GCM is fine for both 1 and 2 layer in COSE,
and 2 layer in JOSE. It is not fine for 1 layer in JOSE.
> The reason for this comes from HPKE:
>
> """
> All the algorithms also take an info parameter that can be used to
> influence the generation of keys (e.g., to fold in identity information)
> and an aad parameter that provides additional authenticated data to the
> AEAD algorithm in use.
> """
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9180%23section-5&data=05%7C02%7C%7Cef2a87382c234d52623b08dc914634ff%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638544977921157410%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=MSqU6IQ9VW6VnuEqrWWJdYWu9QNsSfrtqdurIQ14Q2M%3D&reserved=0<https://datatracker.ietf.org/doc/html/rfc9180#section-5>
>
> ^ This sentence is what implies "alg" values like
> "HPKE-Base-P256-SHA256-A128GCM" instead of "HPKE-Base-P256-SHA256" (since
> this one has no AEAD, and therefore no aad parameter).
HPKE has special AEAD id 0xFFFF for no AEAD.
The only thing it allows is using secret export, which has context
parameter (in addition to info).
HPKE Secret Export can be used to construct Direct Key Agreement.
-Ilari
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
