Thanks for pointing out that we forgot to update the text you cited, Brian.  
I’ll create a PR to correct it.

In my experience, moving to shorter algorithm identifiers was inevitable at 
some point, especially because of people saying that parseable algorithm 
identifiers was a bad idea and could lead to people trying to use nonsensical 
and insecure combinations.

Given that there was going to be a breaking change, it seemed better to get 
through it as soon as possible.  It might have happened at WGLC.  It might have 
happened in IETF review.  It might have happened in IESG review.  But at some 
point, somebody would have forced our hands on this point.  Hopefully this will 
be the last such breaking change.

I’ll also note that this decision is partly informed by a consensus call about 
the COSE HPKE draft.  The question was whether to allow all HPKE combinations 
or to choose a specific set of “ciphersuites” that made practical sense.  The 
overwhelming consensus was to do the latter.

This change (and the corresponding anticipated change at 
https://github.com/cose-wg/HPKE/pull/60) locks the “ciphersuites” decision in 
place.

Hopefully this provides more useful context on the topic.

                                                                -- Mike

From: Brian Campbell <[email protected]>
Sent: Wednesday, December 18, 2024 12:48 PM
To: Michael Jones <[email protected]>
Cc: [email protected]
Subject: Re: [jose] Re: New Version Notification for 
draft-ietf-jose-hpke-encrypt-04.txt

These changes to use shorter algorithm identifiers without touching the text in 
https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt-04#section-8.1
 seems problematic. Particularly the text that says the algorithm ciphersuites 
labels are built according to the scheme: HPKE-<KEM>-<KDF>-<AEAD>.



On Wed, Dec 18, 2024 at 1:00 PM Michael Jones 
<[email protected]<mailto:[email protected]>> wrote:
Draft -04 uses the shorter algorithm identifiers, such as "HPKE-0", for the 
reasons discussed on the list.

                                Best wishes,
                                -- Mike

-----Original Message-----
From: [email protected]<mailto:[email protected]> 
<[email protected]<mailto:[email protected]>>
Sent: Wednesday, December 18, 2024 11:54 AM
To: Michael B. Jones 
<[email protected]<mailto:[email protected]>>; Tirumaleswar 
Reddy.K <[email protected]<mailto:[email protected]>>; Aritra Banerjee 
<[email protected]<mailto:[email protected]>>; Hannes 
Tschofenig <[email protected]<mailto:[email protected]>>; 
Hannes Tschofenig 
<[email protected]<mailto:[email protected]>>; Michael Jones 
<[email protected]<mailto:[email protected]>>; Orie Steele 
<[email protected]<mailto:[email protected]>>; Tirumaleswar 
Reddy <[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>
Subject: New Version Notification for draft-ietf-jose-hpke-encrypt-04.txt

A new version of Internet-Draft draft-ietf-jose-hpke-encrypt-04.txt has been 
successfully submitted by Michael Jones and posted to the IETF repository.

Name:     draft-ietf-jose-hpke-encrypt
Revision: 04
Title:    Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing 
and Encryption (JOSE)
Date:     2024-12-18
Group:    jose
Pages:    19
URL:      https://www.ietf.org/archive/id/draft-ietf-jose-hpke-encrypt-04.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/
HTML:     https://www.ietf.org/archive/id/draft-ietf-jose-hpke-encrypt-04.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt
Diff:     
https://author-tools.ietf.org/iddiff?url2=draft-ietf-jose-hpke-encrypt-04

Abstract:

   This specification defines Hybrid Public Key Encryption (HPKE) for
   use with JSON Object Signing and Encryption (JOSE).  HPKE offers a
   variant of public key encryption of arbitrary-sized plaintexts for a
   recipient public key.

   HPKE works for any combination of an asymmetric key encapsulation
   mechanism (KEM), key derivation function (KDF), and authenticated
   encryption with additional data (AEAD) function.  Authentication for
   HPKE in JOSE is provided by JOSE-native security mechanisms or by one
   of the authenticated variants of HPKE.

   This document defines the use of the HPKE with JOSE.



The IETF Secretariat


_______________________________________________
jose mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to