[{"author": "Andrew Gallagher", "text": "

Sorry, running a couple of minutes late

", "time": "2025-03-20T08:01:27Z"}, {"author": "Benson Muite", "text": "

Can help

", "time": "2025-03-20T08:03:47Z"}, {"author": "Stephen Farrell", "text": "

sorry for being tardy, too many overnight meetings;-)

", "time": "2025-03-20T08:06:11Z"}, {"author": "Daniel Gillmor", "text": "

that's a long fingerprint there, Justus!

", "time": "2025-03-20T08:08:19Z"}, {"author": "Paul Wouters", "text": "

It's an arm print :)

", "time": "2025-03-20T08:17:51Z"}, {"author": "Paul Wouters", "text": "

case default: considered harmful :)

", "time": "2025-03-20T08:18:49Z"}, {"author": "Daniel Gillmor", "text": "

iirc, on the list Simo seemed to think that \"ignoring the traditional part\" during verification would be sufficient to count as CNSA 2.0 compliant

", "time": "2025-03-20T08:28:48Z"}, {"author": "Stephen Farrell", "text": "

@scott: is https://datatracker.ietf.org/doc/draft-becker-cnsa2-tls-profile/ the relevant draft?

", "time": "2025-03-20T08:29:07Z"}, {"author": "Alicja Kario", "text": "

@Daniel yes, but that still needs to use SHA-2 based hashes

", "time": "2025-03-20T08:29:24Z"}, {"author": "Daniel Gillmor", "text": "

Simo's message: https://mailarchive.ietf.org/arch/msg/openpgp/8qr7qJdo6N_4eGklR6hTovtWltU/

", "time": "2025-03-20T08:30:16Z"}, {"author": "Justus Winter", "text": "

don't let it open, help implementers navigate the new algorithms by being explicit

", "time": "2025-03-20T08:31:42Z"}, {"author": "Jonathan Hammell", "text": "

There is no CNSA 2.0 profile for OpenPGP, as far as I'm aware. The closest related one would likely be https://datatracker.ietf.org/doc/draft-becker-cnsa2-smime-profile/ . This I-D says that only pure ML-DSA is allowed, not pre-hash.

", "time": "2025-03-20T08:32:47Z"}, {"author": "Alicja Kario", "text": "

and CNSA2.0 states that if there are no pure options available in the protocols, then hybrids are fine

", "time": "2025-03-20T08:33:48Z"}, {"author": "Daniel Gillmor", "text": "

with no hats on, i have to agree that exporting from an HSM into softkeys is not a use case we need to care about supporting.

", "time": "2025-03-20T08:35:09Z"}, {"author": "Ben S", "text": "

Alicja Kario said:

\n
\n

and CNSA2.0 states that if there are no pure options available in the protocols, then hybrids are fine

\n
\n

(Not a CNSA expert) I thought that only applied if non-hybrid options weren't possible (as is realistically the case in IKE), whereas it'd be easy to specify a non-hybrid algorithm in OpenPGP if it were needed for CNSA 2.0 compliance

", "time": "2025-03-20T08:35:48Z"}, {"author": "Daniel Gillmor", "text": "

also, with no hats on, i think LAMPS' decision here was a terrible result.

", "time": "2025-03-20T08:36:07Z"}, {"author": "Ben S", "text": "

Ben S said:

\n
\n

Alicja Kario said:

\n
\n

and CNSA2.0 states that if there are no pure options available in the protocols, then hybrids are fine

\n
\n

(Not a CNSA expert) I thought that only applied if non-hybrid options weren't possible (as is realistically the case in IKE), whereas it'd be easy to specify a non-hybrid algorithm in OpenPGP if it were needed for CNSA 2.0 compliance

\n
\n

i.e. you can't get around the \"no hybrids\" rule by just choosing to only specify hybrids

", "time": "2025-03-20T08:36:29Z"}, {"author": "Stephen Farrell", "text": "

yep, and to be clear I wasn't asking that we make the same error, just that we see theirs first

", "time": "2025-03-20T08:36:35Z"}, {"author": "Stephen Farrell", "text": "

same error as lamps that is

", "time": "2025-03-20T08:36:47Z"}, {"author": "Alicja Kario", "text": "

from CNSA2.0 FAQ:
\n\"However, product availability and
\ninteroperability requirements may lead to adopting hybrid solutions.\"

", "time": "2025-03-20T08:37:11Z"}, {"author": "Alicja Kario", "text": "

to room, Quynh: who to talk to?

", "time": "2025-03-20T08:40:32Z"}, {"author": "Ben S", "text": "

+1 to Quynh - best way to clarify the CNSA 2.0 position would be to just ask NSA if what we have is acceptable

", "time": "2025-03-20T08:40:40Z"}, {"author": "Alicja Kario", "text": "

@Ben: who to talk to is not exactly obvious though...

", "time": "2025-03-20T08:41:26Z"}, {"author": "Florence D", "text": "

You could start with the authors of the CNSA 2.0 S/MIME draft

", "time": "2025-03-20T08:41:44Z"}, {"author": "Florence D", "text": "

https://datatracker.ietf.org/doc/draft-becker-cnsa2-smime-profile/

", "time": "2025-03-20T08:41:52Z"}, {"author": "Quynh Dang", "text": "

Hope somebody will reply to your question @Alicja. I don't know.

", "time": "2025-03-20T08:42:03Z"}, {"author": "Ben S", "text": "

I think there's a few NSA-ers that are attending IETF remotely. They might not be online yet though

", "time": "2025-03-20T08:42:29Z"}, {"author": "Justus Winter", "text": "

we cannot see Daniel

", "time": "2025-03-20T08:42:59Z"}, {"author": "Justus Winter", "text": "

can we move the speaker cam?

", "time": "2025-03-20T08:43:16Z"}, {"author": "Justus Winter", "text": "

thanks!

", "time": "2025-03-20T08:43:32Z"}, {"author": "Paul Wouters", "text": "

I'll ask meetecho support

", "time": "2025-03-20T08:43:47Z"}, {"author": "Phillip Hallam-Baker", "text": "

oooooh, very different security properties. And quite interesting.

", "time": "2025-03-20T08:43:59Z"}, {"author": "Scott Fluhrer", "text": "

When I said \"the NSA has written a draft about what they want\", I was wrong (sorry). Still, they have strongly stated their insistence on ML-KEM-1024 only and ML-DSA-87 only.

", "time": "2025-03-20T08:45:52Z"}, {"author": "Stephen Farrell", "text": "

@scott: if they continue to dislike hybrids then we have the info

", "time": "2025-03-20T08:46:51Z"}, {"author": "Alicja Kario", "text": "

@Stephen: the FAQ reads as \"We have 100% confidence in pure algorithms so there's no point in wasting resources to accommodate hybrids, be it for key management, or just CPU time to waste on classical algorithms\"; that isn't a straight \"no hybrids under any circumstances\"

", "time": "2025-03-20T08:49:03Z"}, {"author": "Quynh Dang", "text": "

https://www.ietf.org/archive/id/draft-becker-guthrie-cert-binding-for-multi-auth-02.html#name-authors-addresses-2

", "time": "2025-03-20T08:49:08Z"}, {"author": "Quynh Dang", "text": "

@Alicja the 3 authors of the draft above, you could send them an email I guess.

", "time": "2025-03-20T08:49:35Z"}, {"author": "Alicja Kario", "text": "

@Quynh thank you!

", "time": "2025-03-20T08:49:45Z"}, {"author": "Stephen Farrell", "text": "

I guess we can handle that cnsa2 question as part of WGLC if someone wants to assert it's a needed thing?

", "time": "2025-03-20T08:50:15Z"}, {"author": "Stephen Farrell", "text": "

IOW I don't think we've a pressing need to wait for NSA's opinion before proceeding

", "time": "2025-03-20T08:50:39Z"}, {"author": "Daniel Gillmor", "text": "

Simo has been the only person to push on that, and he seemed satisfied (on list) with the changes that Falko reported.

", "time": "2025-03-20T08:50:52Z"}, {"author": "Alicja Kario", "text": "

@Stephen: we (RedHat) do use OpenPGP signatures on RPMs, we do need something that's \"good enough\" for CNSA2.0 compliance (Simo is my coworker)

", "time": "2025-03-20T08:51:34Z"}, {"author": "Scott Fluhrer", "text": "

My opinion: there is no need to block on CNSA-specific ciphersuites. If we decide they are needed, those can be specified in a later RFC

", "time": "2025-03-20T08:52:51Z"}, {"author": "Alicja Kario", "text": "

And we will be aiming for using both ML-DSA (for CNSA2.0) and SLH-DSA (for long-term assurance)

", "time": "2025-03-20T08:53:37Z"}, {"author": "Stephen Farrell", "text": "

@alicja: so you can SLH-away for sigs?

", "time": "2025-03-20T08:53:53Z"}, {"author": "Alicja Kario", "text": "

@stephen: sorry, can't parse the question

", "time": "2025-03-20T08:54:23Z"}, {"author": "Stephen Farrell", "text": "

sorry, g

", "time": "2025-03-20T08:54:32Z"}, {"author": "Stephen Farrell", "text": "

if you can do SLH-DSA isn't that enough for CNSA for sigs?

", "time": "2025-03-20T08:54:52Z"}, {"author": "Falko Strenzke", "text": "

@Alicia: Is CNSA 2.0 compliance for the KEM also a concern?

", "time": "2025-03-20T08:55:53Z"}, {"author": "Alicja Kario", "text": "

@Scott: yes, they can be specified later, but larger interoperability is in general better, and if we can have something CNSA2.0 compliant in general, in first PQC RFC that will be nice... We might be most vocal about wanting support for this, but I'm pretty sure there are other companies that will be interested in that too...

", "time": "2025-03-20T08:56:16Z"}, {"author": "Alicja Kario", "text": "

@Falko: not for us, we need it for software signatures, not encryption

", "time": "2025-03-20T08:57:21Z"}, {"author": "Stephen Farrell", "text": "

personal prediction: some unhappiness will arise if someone suggests we add non-kybrid confid now - but if asking for that is someone's WGLC comment we'll discuss it on the list I guess

", "time": "2025-03-20T08:57:43Z"}, {"author": "Alicja Kario", "text": "

@Stephen: no, SLH-DSA is explicitly disallowed by NSA (which we find rather... weird...)

", "time": "2025-03-20T08:58:00Z"}, {"author": "Stephen Farrell", "text": "

reallyl? yes weird

", "time": "2025-03-20T08:58:38Z"}, {"author": "Falko Strenzke", "text": "

@Stephen: What to you mean by \"non-kybrid confid\"

", "time": "2025-03-20T08:58:44Z"}, {"author": "Stephen Farrell", "text": "

I mean a pure ML-KEM with no ECDH

", "time": "2025-03-20T08:59:09Z"}, {"author": "Stephen Farrell", "text": "

anyway raising theses issues as part of a WGLC seems fine, I don't think we need to wait before if the authors don't

", "time": "2025-03-20T08:59:54Z"}, {"author": "Alicja Kario", "text": "

@Stephen: we are very much in the \"we need hybrids for KEX\" camp. For signatures we think it depends on the use case, with PGP using hybrids being good.

", "time": "2025-03-20T09:01:22Z"}, {"author": "Justus Winter", "text": "

whoa, a primary hmac key?

", "time": "2025-03-20T09:02:15Z"}, {"author": "Stephen Farrell", "text": "

@alicja: that seems in line with earlier WG participant opinion

", "time": "2025-03-20T09:02:15Z"}, {"author": "Stephen Farrell", "text": "

(mind you, my personal opinion is that hybrid-sigs are a bad idea but the WG clearly think otherwise:-)

", "time": "2025-03-20T09:02:47Z"}, {"author": "Daniel Gillmor", "text": "

the fact that an active WG member says \"whoa\" suggests that some text about key structure would be worth drafting :)

", "time": "2025-03-20T09:04:58Z"}, {"author": "Alicja Kario", "text": "

for ephemeral stuff (email)... I can see that. But for software signatures (really long-term stuff), the cost is a bit more on the hybrid side. (but that's minor, as long as we can put multiple sigs it's fine :) )

", "time": "2025-03-20T09:05:03Z"}, {"author": "Justus Winter", "text": "

not sure if i got that right, but i think a primary hmac doesn't make any sense, because you cannot communicate the resulting certificate to anyone, and passing the cert along is what the cert is for

", "time": "2025-03-20T09:05:09Z"}, {"author": "Daniel Gillmor", "text": "

what if passing the cert to your other device is what this particular cert is for?

", "time": "2025-03-20T09:06:09Z"}, {"author": "Daniel Huigens", "text": "

@Justus Winter There is no cert corresponding to the TSK with the primary HMAC key. In a way, I'm thinking of \"TSK bundles\" and \"cert/TPK bundles\" rather than individual keys/certs, and the TPK bundle corresponding to the TSK bundle only includes the asymmetric keys, in general

", "time": "2025-03-20T09:07:56Z"}, {"author": "Justus Winter", "text": "

so using openpgp as a protocol between mutually trusting peers, seems a bit over the top, but i guess if you have openpgp in your toolkit, you might as well just use it

", "time": "2025-03-20T09:08:03Z"}, {"author": "Daniel Huigens", "text": "

So the TSK with the symmetric algorithms is only for your personal use, you wouldn't transfer it to someone else, only possibly between your own devices

", "time": "2025-03-20T09:08:45Z"}, {"author": "Daniel Gillmor", "text": "

option 0 :+1:

", "time": "2025-03-20T09:10:02Z"}, {"author": "Daniel Huigens", "text": "

(And yes I can add some text about this to the draft if it's non-obvious)

", "time": "2025-03-20T09:10:25Z"}, {"author": "Daniel Gillmor", "text": "

and, this is also concretely useful for post-quantum transition

", "time": "2025-03-20T09:11:34Z"}, {"author": "Justus Winter", "text": "

what is a \"detached revocation\"?

", "time": "2025-03-20T09:15:17Z"}, {"author": "Justus Winter", "text": "

a revocation signature without the revoked primary key? if so, please just don't do that, that is terrible to consume as implementation, and will make the revocation much less robust.

", "time": "2025-03-20T09:16:08Z"}, {"author": "Stephen Farrell", "text": "

@justus: maybe jump in queue? we've only 14 mins remainign

", "time": "2025-03-20T09:17:00Z"}, {"author": "Daniel Gillmor", "text": "

Justus, i think you're suggesting sending https://www.rfc-editor.org/rfc/rfc9580.html#name-openpgp-version-6-revocatio instead of an independent revocation signature packet.

", "time": "2025-03-20T09:17:53Z"}, {"author": "Stephen Farrell", "text": "

DKIM? :-)

", "time": "2025-03-20T09:17:58Z"}, {"author": "Justus Winter", "text": "

@dkg, exactly

", "time": "2025-03-20T09:21:25Z"}, {"author": "Justus Winter", "text": "

@dkg, I think revocation should be a key flag

", "time": "2025-03-20T09:25:41Z"}, {"author": "Justus Winter", "text": "

then, if you want to designate me as a revoker for your cert, you bind my revocation subkey to your certificate

", "time": "2025-03-20T09:26:25Z"}, {"author": "Daniel Gillmor", "text": "

Justus, please comment on https://gitlab.com/dkg/openpgp-revocation/-/merge_requests/10 or offer an alternative \u263a

", "time": "2025-03-20T09:26:53Z"}, {"author": "Stephen Farrell", "text": "

just checking does anyone hav any AOB items? If so, typing those here would be good

", "time": "2025-03-20T09:27:35Z"}, {"author": "Justus Winter", "text": "

ah, I will, this is a thought I came up with just recently

", "time": "2025-03-20T09:29:07Z"}, {"author": "Justus Winter", "text": "

thanks everyone, see you soon

", "time": "2025-03-20T09:32:22Z"}, {"author": "Benson Muite", "text": "

thanks

", "time": "2025-03-20T09:32:32Z"}]