Return-Path: X-Original-To: cfrg@mail2.ietf.org Delivered-To: cfrg@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 56D6A7E66C49 for ; Wed, 29 Oct 2025 14:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20230601.gappssmtp.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M_E-MWql91T for ; Wed, 29 Oct 2025 14:04:05 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id D47417E6687B for ; Wed, 29 Oct 2025 14:03:30 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id e9e14a558f8ab-430d098121cso1171695ab.0 for ; Wed, 29 Oct 2025 14:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20230601.gappssmtp.com; s=20230601; t=1761771810; x=1762376610; darn=irtf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dQ49dfctiW5xG8+nki0mMbTYi+O+JgmzaxE9nk+No0s=; b=ytgjNiBNx9Y95XxCjcSVDz6B6huuW7zjqBxTCrM1n24l3oBFM6StIc+96tAVB3hbsy G4bwmUlLD3CJNPwPTdEknQZkTs88+1aRLX81cedW5J/Xj9TeLqUioINHJMUVI5odXnem KHHIUxxSpazMve368yPe110J5Glq4pwhczT6Um304lGHrFWe4AUs27nExUTVech0oFvt oGXWRe77cdxhfg8pDvzKqTp8pPtiK/1GsSp21O8+vMlmr94Evra+tWHiRPTK02NMdt9v U7ZQG5QO/MDsMVuZPghyJFp9TsHsw+9L1O63SiSzIQu3ojMBeuSeD6IJkVDY4plT1PK3 igKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761771810; x=1762376610; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dQ49dfctiW5xG8+nki0mMbTYi+O+JgmzaxE9nk+No0s=; b=w/0GvPNRgXvmYLalu2zNNEDa1bEV/dtQjEaK4wyMYbCWwwFolB5H1tJpFIVVX0FOQe aNDynPSzStXjEi2QzI2XhWMaTgCSzuPOdNe2vGvnjfbxS0nwfLcmK4+jIc+Hy7PounnN PAd4H5qx6xgLr8Z1lwtJpQVgohi6UyTRjE0hlgjbaWYdlRwetK2cf3NtyUr/7wraE5dj bALz39MCDI4FDRN0lFxBzAo5nOG+p+6ZRtiFoa5/I885FjuYgWT1XqA1TDxFVzhRwspK h67buCxr3ZZHmArutE84jAfNPdiWcNhtDvUGzOUul5g9CmjuGlMoLvfJKfYIWkh0ESK3 CXtg== X-Gm-Message-State: AOJu0YzAGgZAJ0exVxY6Ob7l9bV7VzFprzGiLOEjdWwiUgWzmMZrMO8s baigElh/RVjIbHg3qn+IOzfWgEkGyaozrbihUdVyDIxzm62J8ifGQmlAQtgCtKsUIpEGsiIHOxr qlzy9kwAcMAzpXatxqk5FznJ4ar8NN1byQmSr0+Uh1g== X-Gm-Gg: ASbGnctAkn4DKSOr0LN0vAMBBrvVWcmn3x+pKwP2gBVSRnP3JeYXfCPiby4agtLzyIc sHR20lhRbbuaV27UyPDNWc9sgpYFTNRu8p0GmKqvtY9NOcW/kq+c2895L83ogYpFbfCJKMi51G1 hlGjodrA2TVm9lNhdQkRAVp5h+VGnQjPH/kUey+HH/zlCJqpDal8AvfXWvjxOUDLqeEQyXzuHfT J+CrxkezGbtSXCA9g1Ura6WvQu7FmQKum1dxcaQGccE7CDwTfbtjoxNew== X-Google-Smtp-Source: AGHT+IH4th9RwacZJX57rmL1gHRNmTDdee5hD1xT0zTH1ZJTvAvqsDwHZOmaHTpQWo632/kIeWLShh6DObjXUfAztCo= X-Received: by 2002:a05:6e02:3486:b0:430:aec5:9bee with SMTP id e9e14a558f8ab-432f8f871a8mr51741965ab.7.1761771808965; Wed, 29 Oct 2025 14:03:28 -0700 (PDT) MIME-Version: 1.0 References: <2D85ACB8-26D1-4E42-B4BE-DD5CD9BDE33A@nps.edu> <2eff0118-f6c9-4292-b28d-c12e7aefc358@dennis-jackson.uk> In-Reply-To: <2eff0118-f6c9-4292-b28d-c12e7aefc358@dennis-jackson.uk> From: Richard Barnes Date: Wed, 29 Oct 2025 11:03:17 -1000 X-Gm-Features: AWmQ_bkMHcrYhT1pbYYU_LBClKuCp3LVarzwZz-WfONtRJLS2Jg4RlcmPmExmKM Message-ID: To: Dennis Jackson Content-Type: multipart/alternative; boundary="000000000000d9646f0642527617" Message-ID-Hash: QXG6QENMUHPLQAEDQ6CR6QWMTCJGXUVA X-Message-ID-Hash: QXG6QENMUHPLQAEDQ6CR6QWMTCJGXUVA X-MailFrom: rlb@ipv.sx X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; header-match-cfrg.irtf.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: cfrg@irtf.org, LAMPS , hpke@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_=5Bhpke=5D_Re=3A_Re=3A_Re=3A_Re=3A_New_labels_in_?= =?utf-8?q?draft-irtf-cfrg-concrete-hybrid-kems-01?= List-Id: Crypto Forum Research Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000d9646f0642527617 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW, here's a PR that does just that: https://github.com/cfrg/draft-irtf-cfrg-concrete-hybrid-kems/pull/37 On Wed, Oct 29, 2025 at 11:02=E2=80=AFAM Dennis Jackson wrote: > My understanding is that the new labels in the CFRG draft were chosen > because nobody could agree on what human readable content to include. > > The timing around when the drafts landed & the communication around the > label change has made things messy and I totally get the frustration ther= e. > > A pragmatic way forward would be to just use the hex and drop the ASCII > from the cfrg draft: > > 0x7C2D28292D7C for X-Wing > 0x5C2E2F2F5E5C for P256-ML-KEM1024 > 0x207C202F2D5C for P384-ML-KEM1024 > > These numbers are as good as any other and it paves over the issues folks > already ran into with the (unchangeable) X-Wing label. > > Best, > Dennis > On 29/10/2025 20:43, Eric Rescorla wrote: > > Following up to myself.... I'm also fine with the LAMPS strings. > > -Ekr > > > On Wed, Oct 29, 2025 at 1:27=E2=80=AFPM Eric Rescorla wrot= e: > >> I would make a few points here: >> >> I don't have a strong opinion on whether we ought to have structured >> strings or just 6-byte constants but ISTM that having the spec contain >> strings which contain special characters are a clear safety hazard, and = the >> only motivation for them seems to be to make a Star Wars joke, which rea= lly >> doesn't seem like a priority for the RG. That seems more like a bug than= a >> feature to me. With that said, while the X-wing label is unfortunate, I >> don't think anyone is proposing to change it, but no such considerations >> exist for the other value. To that end, I propose the following: >> >> - Render the labels only as hex values. >> - Replace the non-X-wing labels with values which don't happen to >> correspond to escape characters. The obvious thing to do here is just to >> use a simple counter, so we can use (x00...00 and 0x00..02) but I could >> imagine other approaches. >> >> The net effect of these is to slightly reduce the surface area for error= s >> without creating an interop problem or arguments about the semantics of = the >> strings. >> >> Finally, I would observe that arguments of the form "we need to get >> things out now so we need to do things the way I prefer" are less >> persuasive than "we need to get this now so I'm prepared to do things a = way >> I don't really like". >> >> -Ekr >> >> >> >> On Wed, Oct 29, 2025 at 1:11=E2=80=AFPM Sophie Schmieg >> wrote: >> >>> The labels are simple numeric codepoints: >>> 0x7C2D28292D7C for X-Wing >>> 0x5C2E2F2F5E5C for P256-ML-KEM1024 >>> 0x207C202F2D5C for P384-ML-KEM1024 >>> in little endian. >>> And yes, I concur with Filippo, we need to be able to ship without bein= g >>> held up by discussions on naming things, and simple numerical values li= ke >>> the ones above allow us to do just that. >>> >>> On Wed, Oct 29, 2025 at 12:17=E2=80=AFPM Hale, Britta (CIV) >> 40nps.edu@dmarc.ietf.org> wrote: >>> >>>> I concur with keeping clear and human-readable ciphersuites (e.g., >>>> =E2=80=9CQSF-P256-MLKEM768-SHAKE256-SHA3256=E2=80=9D). Post quantum mi= gration is >>>> challenging enough without adding a further mapping that humans can >>>> mis-interpret, which can itself lead to introduction of vulnerabilitie= s >>>> while attempting use of post quantum algorithms. >>>> >>>> >>>> >>>> If there are any cases where shorthand is absolutely needed (e.g., in >>>> specific WGs where counting bytes matters), then reference strings oug= ht to >>>> be simple such as a numeric mapping to specific suites. ASCII art make= s it >>>> difficult to ensure correctness, even among knowledgeable individuals,= as >>>> is evident by the examples already encountered. We should not be makin= g >>>> standards intentionally more difficult to follow for less experienced >>>> individuals. >>>> >>>> >>>> >>>> Britta >>>> >>>> >>>> >>>> >>>> >>>> *From: *Mike Ounsworth >>>> *Date: *Wednesday, October 29, 2025 at 11:11=E2=80=AFAM >>>> *To: *Eric Rescorla >>>> *Cc: *LAMPS WG , CFRG , "hpke@ietf.org" >>>> >>>> *Subject: *[CFRG] Re: New labels in >>>> draft-irtf-cfrg-concrete-hybrid-kems-01 >>>> >>>> >>>> >>>> NPS WARNING: *external sender* verify before acting. >>>> >>>> >>>> >>>> As as pointed out by Daniel Van Geest in another thread, the label >>>> for MLKEM1024-P384 is supposed to be " | /-\", but in the published ve= rsion >>>> of the cfrg draft (both HTML and TXT), it displays as ` | /-` (note th= e >>>> missing backslash). So that means that the kramdown2rfc tooling is not >>>> handling this properly. >>>> >>>> >>>> >>>> So when I said "This is GOING to lead to at least incompatibilities if >>>> not CVEs" I didn't realize that we already had one in the draft. >>>> >>>> >>>> >>>> The point is this: >>>> >>>> The LAMPS doc is already in WGLC (months later than we wanted), using >>>> the labels from YOUR -00 (minus the SHAKE256 component). I made that c= hange >>>> in consultation with you guys as part of the CRFC Interim in Sept. You= r doc >>>> is not in WGLC yet, so can you please change your labels to match? >>>> >>>> >>>> >>>> On Wed, 29 Oct 2025 at 12:47, Eric Rescorla wrote: >>>> >>>> I can't speak for what has or has not happened in terms of interop, bu= t >>>> on the >>>> >>>> substance of the labels I agree with Mike. I strongly prefer simple >>>> human-readable >>>> >>>> labels to ASCII art Star Wars references, no matter how clever those >>>> references >>>> >>>> might be. >>>> >>>> >>>> >>>> -Ekr >>>> >>>> >>>> >>>> On Wed, Oct 29, 2025 at 10:36=E2=80=AFAM Mike Ounsworth < >>>> ounsworth+ietf@gmail.com> wrote: >>>> >>>> draft-irtf-cfrg-concrete-hybrid-kems-01 publish on Oct 20 and made the >>>> following label changes: >>>> >>>> >>>> >>>> >>>> >>>> "QSF-P256-MLKEM768-SHAKE256-SHA3256" --> "|-()-|" >>>> >>>> "QSF-P384-MLKEM1024-SHAKE256-SHA3256" --> " | /-" >>>> >>>> >>>> >>>> Please tell me this is a joke. Then please remove this from the draft >>>> and put the labels back to sane alphanumeric. I'm sorry for strong lan= guage >>>> below, but this makes me mad. >>>> >>>> I have been bending over backwards to make the LAMPS thing match the >>>> HPKE thing, including multiple rounds of interop-testing against your = test >>>> vectors and changing the LAMPS draft, reference impl, and test vectors= to >>>> match yours. This has resulted in delayed publication of the LAMPS dra= ft by >>>> several months to accommodate interop with the HPKE draft. The LAMPS >>>> Composite-KEM doc went into WGLC on Oct 17 now using HPKE-style labels= of >>>> the form "QSF-MLKEM768-P256-SHA3256" that we pulled FROM YOUR DRAFT in= stead >>>> of the OID-based labels we had before. Then on Oct 20 you publish a ne= w >>>> version that goes and changes the labels to this nonsense. Can you guy= s >>>> please at least pretend like you care about interop between these two = docs? >>>> >>>> My specific objections to more ASCII art labels: >>>> >>>> 1. We're already having interop problems at the PQC hackathon group >>>> because of the backslash in the xwing label -- for example, in python = you >>>> have to put the constant in your source code as "\\.//^\\" to prevent = it >>>> from interpreting that as an escaped dot and double-quote. We've also = had >>>> similar problems representing this label properly in HTML and markdown >>>> docs. Now you want more labels that have both backslashes and now spac= es. >>>> This is GOING to lead to at least incompatibilities if not CVEs. >>>> >>>> 2. The label is not human-readable; it doesn't tell my anything useful >>>> about the content, nor will it be easy to debug mistakes in source cod= e or >>>> config files. At this point, assigning a numeric codepoint would be >>>> preferable. >>>> >>>> 3. This does not establish a naming convention that is easily >>>> extensible to other hybrid combinations. >>>> >>>> I have been doing everything in my power to work behind the scenes to >>>> get interop between these two documents, and it feels like you guys ar= e >>>> doing everything in your power to obstruct it. >>>> >>>> >>>> Can you please put your labels back so that they match the LAMPS draft >>>> using the pattern "QSF-MLKEM768-P256-SHA3256". >>>> >>>> >>>> >>>> (PS this is a re-send from the correct email address) >>>> >>>> >>>> -Mike >>>> >>>> _______________________________________________ >>>> CFRG mailing list -- cfrg@irtf.org >>>> To unsubscribe send an email to cfrg-leave@irtf.org >>>> >>>> _______________________________________________ >>>> hpke mailing list -- hpke@ietf.org >>>> To unsubscribe send an email to hpke-leave@ietf.org >>>> >>> >>> >>> -- >>> >>> Sophie Schmieg | Information Security Engineer | ISE Crypto | >>> sschmieg@google.com >>> >>> > _______________________________________________ > CFRG mailing list -- cfrg@irtf.org > To unsubscribe send an email to cfrg-leave@irtf.org > > _______________________________________________ > hpke mailing list -- hpke@ietf.org > To unsubscribe send an email to hpke-leave@ietf.org > --000000000000d9646f0642527617 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 29= , 2025 at 11:02=E2=80=AFAM Dennis Jackson <ietf=3D40dennis-jackson.uk@dmarc.ietf.org> = wrote:
=20 =20 =20

My understanding is that the new labels in the CFRG draft were chosen because nobody could agree on what human readable content to include.=C2=A0

The timing around when the drafts landed & the communication around the label change has made things messy and I totally get the frustration there.

A pragmatic way forward would be to just use the hex and drop the ASCII from the cfrg draft:

0x7C2D28292D7C for X-Wing
0x5C2E2F2F5E5C for P256-ML-KEM1024
0x207C202F2D5C for P384-ML-KEM1024

These numbers are as good as any other and it paves over the issues folks already ran into with the (unchangeable) X-Wing label.

Best,
Dennis

On 29/10/2025 20:43, Eric Rescorla wrote:
=20
Following up to myself.... I'm also fine with the LAMPS strings.

-Ekr


On Wed, Oct 29, 2025 at 1:27=E2=80=AFPM Eric Rescorla <ekr@rtfm.com> wrote:
I would make a few points here:

I don't have a strong opinion on whether we ought to have structured strings=C2=A0or just 6-byte constants but IST= M that having the spec contain strings which contain special characters are a clear safety hazard, and the only motivation for them seems to be to make a Star Wars joke, which really doesn't seem like a priority for the RG. Tha= t seems more like a bug than a feature=C2=A0to me. With that said, while the X-wing label is unfortunate, I don't thin= k anyone is proposing to change it, but no such considerations exist for the other value. To that end, I propose the following:

- Render the labels only as hex values.
- Replace the non-X-wing labels with values which don'= t happen to correspond to escape characters. The obvious thing to do here is just to use a simple counter, so we can use (x00...00 and 0x00..02) but I could imagine other approaches.

The net effect of these is to slightly reduce the surface area for errors without creating an interop problem or arguments about the semantics of the strings.=C2= =A0

Finally, I would observe that arguments of the form "= we need to get things out now so we need to do things the way I prefer" are less persuasive than "we need to get = this now so I'm prepared to do things a way I don't really like".

-Ekr



On Wed, Oct 29, 2025 at 1:11=E2=80=AFPM Sophie Schmieg <sschmieg@google.com> wrote:
The labels are simple numeric codepoints:
0x7C2D28292D7C for X-Wing
0x5C2E2F2F5E5C for P256-ML-KEM1024
0x207C202F2D5C for P384-ML-KEM1024
in little endian.
And yes, I concur with Filippo, we need to be able to ship without being held up by discussions on naming things, and simple numerical values like the ones above allow us to do just that.

On Wed, Oct 29, 2025 at 12:17=E2=80=AFPM Hale, Britta (CIV) <britta.hale=3D= 40nps.edu@dma= rc.ietf.org> wrote:

I concur with keeping clear and human-readable ciphersuites (e.g., =E2=80=9CQSF-P256-MLKEM768-SHAKE256-SHA3256= =E2=80=9D). Post quantum migration is challenging enough without adding a further mapping that humans can mis-interpret, which can itself lead to introduction of vulnerabilities while attempting use of post quantum algorithms.

=C2=A0

If there are any cases where shorthand is absolutely needed (e.g., in specific WGs where counting bytes matters), then reference strings ought to be simple such as a numeric mapping to specific suites. ASCII art makes it difficult to ensure correctness, even among knowledgeable individuals, as is evident by the examples already encountered. We should not be making standards intentionally more difficult to follow for less experienced individuals.

=C2=A0

Britta

=C2=A0

=C2=A0

From: Mike Ounsworth <ounsworth+ietf@gmail.com>
Date: Wednesday, October 29, 2025 at 11:11=E2=80=AFAM
To: Eric Rescorla <ekr@rtfm.com>
Cc: LAMPS WG <spasm@ietf.org>, CFRG <cfrg@irtf.org>, "hpke@ietf.org" <hpke@ietf.org>
Subject: [CFRG] Re: New labels in draft-irtf-cfrg-concrete-hybrid-kems-01

=C2=A0

NPS WARNING: *external sender* verify before acting.

=C2=A0

As as pointed out by Daniel Van Geest in another thread, the label for=C2=A0MLKEM1024-P384 is supposed t= o be " | /-\", but in the published version of the cfrg draft (both HTML and TXT), it displays as=C2=A0` | /-` (note the missing backslash). So that means that the kramdown2rfc tooling is not handling this properly.

=C2=A0

So when I said "T= his is GOING to lead to at least incompatibilities if not CVEs" I didn&= #39;t realize that we already had one in the draft.

=C2=A0

The point is this:

The LAMPS doc is already in WGLC (months later than we wanted), using the labels from YOUR -00 (minus the SHAKE256 component). I made that change in consultation with you guys as part of the CRFC Interim in Sept. Your doc is not in WGLC yet, so can you please change your labels to match?

=C2=A0

On Wed, 29 Oct 2025 at 12:47, Eric Rescorla <ekr@rtfm.com> wrote:

I can't speak= =C2=A0for what has or has not happened in terms of interop, but on the

substance of the labels I agree with Mike. I strongly prefer simple human-readable

labels to ASCII art Star Wars references, no matter how clever those references

might be.

=C2=A0

-Ekr

=C2=A0

On Wed, Oct 29, 2025 at 10:36=E2=80=AFAM Mike Ounsworth <ounsworth+ietf@gmail.com&= gt; wrote:

draft-irtf-cfr= g-concrete-hybrid-kems-01 publish on Oct 20 and made the following label changes:

=C2=A0

=C2=A0

"QSF-P256= -MLKEM768-SHAKE256-SHA3256" -->=C2=A0 "|-()-|"

"QSF-P384= -MLKEM1024-SHAKE256-SHA3256" --> " | /-"



Please tell me this is a joke. Then please remove this from the draft and put the labels back to sane alphanumeric. I'm sorry fo= r strong language below, but this makes me mad.

I have been bending over backwards to make the LAMPS thing match the HPKE thing, including multiple rounds of interop-testing against your test vectors and changing the LAMPS draft, reference impl, and test vectors to match yours. This has resulted in delayed publication of the LAMPS draft by several months to accommodate interop with the HPKE draft. The LAMPS Composite-KEM doc went into WGLC on Oct 17 now using HPKE-style labels of the form "QSF-MLKEM768-P256-SHA3256&quo= t; that we pulled FROM YOUR DRAFT instead of the OID-based labels we had before. Then on Oct 20 you publish a new version that goes and changes the labels to this nonsense. Can you guys please at least pretend like you care about interop between these two docs?

My specific objections to more ASCII art labels:

1. We're already having interop problems at the PQC hackathon group because of the backslash in the xwing label -- for example, in python you have to put the constant in your source code as "\\.//^\\" to pre= vent it from interpreting that as an escaped dot and double-quote. We've also had similar problems representing this label properly in HTML and markdown docs. Now you want more labels that have both backslashes and now spaces. This is GOING to lead to at least incompatibilities if not CVEs.

2. The label is not human-readable; it doesn't tell my anything=C2=A0useful about the content, nor will it be easy to debug mistakes in source code or config files. At this point, assigning a numeric codepoint would be preferable.

3. This does not establish a naming convention that is easily extensible to other hybrid combinations.

I have been doing everything in my power to work behind the scenes to get interop between these two documents, and it feels like you guys are doing everything in your power to obstruct it.


Can you please put your labels back so that they match the LAMPS draft using the pattern "QSF-MLKEM768-P256-SHA3256&quo= t;.

=C2=A0

(PS this is a re-send from the correct email address)


-Mike

__________________= _____________________________
CFRG mailing list -- cfrg@irtf.org
To unsubscribe send an email to cfrg-leave@irtf.org

_______________________________________________
hpke mailing list -- hpke@ietf.org
To unsubscribe send an email to hpke-leave@ietf.org


--

Sophie Schmieg=C2=A0|=C2=A0Information Security Engineer=C2=A0|=C2=A0ISE Crypto=C2=A0|=C2=A0sschmieg@google.com


_______________________________________________
CFRG mailing list -- cfr=
g@irtf.org
To unsubscribe send an email to cfrg-leave@irtf.org
_______________________________________________
hpke mailing list -- hpk= e@ietf.org
To unsubscribe send an email to hpke-leave@ietf.org
--000000000000d9646f0642527617--