Hi Orie,
Sorry for the late reply. I think I will be able to respond more quickly
starting from this week...
Thank you for the feedback on my draft.
I think there are several topics mixed in this thread, but first, I'd like
to comment on whether this draft should be merged into the existing
COSE-HPKE spec.
The reasons why I proposed this draft as an independent specification
separate from COSE-HPKE are as follows:
a) I wanted to define not only COSE_Key but also JWK representation
together for HPKE. This is the biggest reason.
b) Key representation is essentially independent of the COSE message format
and can be used for various applications unrelated to COSE or JOSE. As I
mentioned in the slides for IETF116, I thought it would be beneficial for
applications using HPKE for end-to-end encryption over HTTP if the HPKE
recipient's public key could be published at the .well-known/jwks endpoint.
COSE_Key representation may also be useful for CoAP-based end-to-end
encryption apps in the same way.
c) I wanted to consolidate the definitions of all expected alg values
(HPKE-v1-{Base, Auth, PSK, AuthPSK}) into one document. Although I had
agreed with the opinion that the COSE-HPKE should focus only on the Base
mode, I thought it would be better to have all alg values for HPKE modes
consolidated into one document. If this draft is adopted as a working group
document, I was thinking of proposing to move the definition of alg values
from the COSE-HPKE spec to this draft.
Regarding (a), for example, the key representation for secp256k1 has both
JWK and COSE_Key formats defined (RFC8812), and the recent post-quantum key
representation proposed by Mike Prorock also has both JWK and COSE_Key
formats defined. If we follow recent conventions, it would be better to
define both COSE_Key and JWK representations together, don't you think? As
I also mentioned in the slides for IETF116, in the EUDCC (EU Digital COVID
Certificate) where COSE has been adopted, the public keys for signature
verification were distributed in JWK format. JWK format is also useful for
COSE.
If it is concluded that JWK should not be defined together, and that the
definition of key representation should be limited to the HPKE Base mode,
and that other HPKE modes should not be defined at this point, then it may
indeed be better to merge this draft into the COSE-HPKE spec. On the other
hand, if there is room for discussion on these issues, I think it would be
appropriate to consider it as an independent draft currently. We can merge
it into the COSE-HPKE spec at any time. What do you think?
Best,
AJITOMI Daisuke
2023年4月16日(日) 14:12 Ilari Liusvaara <[email protected]>:
> On Sat, Apr 15, 2023 at 10:33:37AM -0500, Orie Steele wrote:
> > Thank you for this wonderful breakdown!
> >
> > On Fri, Apr 14, 2023 at 4:00 PM Laurence Lundblade <
> [email protected]>
> > wrote:
> >
> > When we say "public key" in a CRFG document, I think it is reasonable to
> > assume no specific representation (JWK, COSE Key, PGP, etc...)
> >
> > As a side note, HPKE requires more than just having a recipient public
> key,
> > it also requires knowledge of the recipient supported algorithms... (this
> > is extremely obvious per the security considerations).
> > It is natural to assume this will be solved differently in COSE, PGP,
> > etc...
> > Maybe it is in the key representation, maybe it is via negotiation, as
> you
> > mentioned earlier...
> >
> > But it has to actually be solved for, or the sender is just guessing that
> > the recipient will be able to process their messages.
>
> Well, in store-and-forward system like COSE or JOSE, there are really
> only two ways:
>
> - negotiation.
> - assume based on application.
>
> And when it comes to COSE and JOSE, there are no usable negotation
> capabilties, so it is the latter: assuming based on application.
>
>
> > When we say "public key" in a COSE WG document,
> > folks will want to be sure if we are talking about the "abstract concept
> of
> > a public key"
> > or a concrete serialization conforming to normative requirements (JWK
> > Public Key or COSE Public Key).
> >
> > Holding a JWK or COSE "public key" with an algorithm, 🔥 has historically
> > meant 🔥 holding a recipient's encryption preferences.
>
> No, this is not correct. And this has been the case since the first
> RFCs for both.
>
>
> > There is no precedent for COSE Key or JWK containing "preferences for
> > parameterization" in addition to a "restriction of key use".
>
> However, there is precedent for parametrization. For both COSE and
> JOSE, since the first RFCs.
>
>
> > You can imagine COSE HPKE asking IANA to update the COSE registry to
> > communicate that "hkc" is bound to a specific value of "alg", similar to
> > how -27 is bound to "kty".
> > (! 🔥 kty and alg confusion intensifies... )
>
> There is no precedent for key parameter being bound to "alg". Being
> bound to "kty" yes (that is the difference between the two kinds of
> key parameters in COSE). And in JOSE, analogous split exists, even if
> it is not explicit in registeries.
>
>
> > ... I prefer to imagine requesting registration of a few good choices for
> > HPKE COSE (to start), and not importing every option under the sun by
> > default from the CFRG established registries here:
> >
> > How many other preferences would we need to register? Only the ones
> people
> > actually want to use, and *they* need to do *some* work to justify why
> this
> > is a good idea...
>
> With a few plausible extensions to HPKE, over 70.
>
> As for how many there currently would be, either 12 or *none at all*,
> depending on how exactly one defines things.
>
>
> > we don't just hand out a blank check, and leave COSE implementers on the
> > hook for an ever expanding bill of CFRG registered algorithms.
>
> Currently, it is not COSE-HPKE that is on the hook for HPKE algorithms,
> it is HPKE itself. Just modified my test code to make the following
> work (with COSE-HPKE code having absolutely no idea what is going on):
>
> $ target/debug/cose-hpke-keygen /tmp/mystery-key.key TYPE21
> $ echo "The crow flies at midnight" >/tmp/message
> $ target/debug/cose-hpke-encrypt --algorithm=TYPE2 /tmp/message
> /tmp/mystery-key.key.pub
> $ target/debug/cose-hpke-decrypt /tmp/message.chpke
> /tmp/mystery-key.key.priv
> $ cat /tmp/message.chpke.decrypted
> The crow flies at midnight
> $
>
> In contrast, registering explicit algs would make COSE implementers to
> be on hook for the bill.
>
> And for JWK, explicit algs is non-starter.
>
>
> > HPKE is not actually usable in COSE without some work from this working
> > group,
> > we should not defer our responsibility to the (first ever, IIRC) CFRG
> > established registry,
> > it is not going to feel good for developers, if we try to start a 5 guy
> > revolution while the world is trying to upgrade to post quantum
> encryption.
>
> HPKE and its implementation has to update anyway for post-quantum.
>
> But does COSE-HPKE and its implementation *also* have to update for
> post-quantum?
>
> With updated HPKE implementation, in the example above, replacing
> "TYPE21" with "TYPE30" would have enabled Post-Quantum.
>
> TODO: Make the code dynamically link against HPKE library.
>
>
> > > Up until COSE_HPKE, 1) and 2) are a single integer ciphersuite.
> Probably
> > > anyone doing 3) up to until COSE_HPKE would also use the single
> integer too.
> > >
> >
> > Agreed.
>
> I don't agree. Even ignoring keys, no single integer ciphersuite ever
> existed in COSE.
>
>
> > > draft-ietf-cose-hpke has addressed 1) with the new HPKE_sender_info
> header
> > > parameter. Now the algorithm used is a special ciphersuite identifier
> that
> > > indicates further details in an additional parameter.
> > >
> > Agreed, there are "proposals for revolution", which I am all for, if they
> > are coming from enough reviewers / implementers.
> > I am happy to withdraw my objection if overwhelmed by counter arguments,
> I
> > don't find the current arguments from Ilari compelling, but I appreciate
> > his consistent engagement.
>
> If performing asymmetric encryption with COSE or JOSE, there is already
> further details in additional parameter.
>
>
> > > - In COSE_HPKE we’re requiring algorithm identification be made up of a
> > > special ciphersuite and a triple. This will/should apply in all
> contexts
> > > where COSE algorithm IDs are used. Maybe we should try to unify the
> > > definition of this in draft-ietf-cose-hpke
> > > and draft-ajitomi-cose-cose-key-jwk-hpke-kem?
> > >
> > I don't think we need another document.
> >
> > I think we should bend the knee to convention in COSE HPKE, even over the
> > objections of Ilari and Daisuke... (assuming they persist in advocating
> for
> > parameterization of alg).
> >
> > UNLESS, we have clear consensus on proceeding with a revolution, for
> that I
> > would want to see a lot more engagement :)
>
> Well, speaking for myself, I will continue advocating parametrization.
>
> Engagement seems to be very limited for COSE-HPKE.
>
>
> > > My opinions on 3) are:
> > > - The use cases are too widely varying for anyone to define an actual
> > > protocol
> > > - draft-ajitomi-cose-cose-key-jwk-hpke-kem can only work for a small
> > > fraction of negotiation use cases — those that use COSE_Key for
> negotiation
> > > - We might generalize the HPKE COSE algorithm identifier definition so
> the
> > > same thing can be used for 1), 2) and 3). That is probably splitting
> HPKE_sender_info
> > > into two, one structure that is the algorithm ID and one is the enc
> info.
> > > We still wouldn’t define actual protocol for 3) but we would have a
> clear
> > > common method for COSE HPKE algorithm identification that anyone could
> use
> > > for their use-case specific negotiation protocol.
> > >
> > I agree with you on 3.
>
> I do not see how that would work.
>
> And I think that negotiation mechanism that would work for majority of
> use cases would be straightforward extension of the key draft. No
> splitting needed.
>
> The question is, given that we have not needed negotiation mechanism in
> the past, why do we need one now?
>
>
>
> -Ilari
>
> _______________________________________________
> COSE mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cose
>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
