[{"author": "Daniel Gillmor", "text": "

I've just pre-populated the notes with the high-level agenda, but i won't have capacity to take notes as well

", "time": "2024-03-19T23:30:06Z"}, {"author": "Stephen Farrell", "text": "

we have notetakers, Rich and Quynh

", "time": "2024-03-19T23:31:34Z"}, {"author": "Aron Wussler", "text": "

Is there a hush-hush way to get RFC 9760?

", "time": "2024-03-19T23:36:00Z"}, {"author": "Mike Ounsworth", "text": "

\"Fun RFC numerology\" -dkg
\nIs so far the quote of the day.

", "time": "2024-03-19T23:38:44Z"}, {"author": "Daniel Gillmor", "text": "

daniel huigens is in the queue

", "time": "2024-03-19T23:44:26Z"}, {"author": "Daniel Gillmor", "text": "

re: smartcards: please see also draft-dkg-openpgp-hardware-secrets

", "time": "2024-03-19T23:47:15Z"}, {"author": "Daniel Gillmor", "text": "

do we know about hardware compatibility of P-384 vs P-256?

", "time": "2024-03-19T23:52:54Z"}, {"author": "Justus Winter", "text": "

We don't worry about codepoint exhaustion here, if we would, we would have introduced 16 bit codepoints with v6

", "time": "2024-03-19T23:54:26Z"}, {"author": "Mike Ounsworth", "text": "

Daniel Gillmor said:

\n
\n

re: smartcards: please see also draft-dkg-openpgp-hardware-secrets

\n
\n

Is that draft essentially \"Attested OpenPGP\" by carrying a whole TPM attestation?
\nOr is that draft just a single boolean: HardwareBacked:TRUE ?

", "time": "2024-03-19T23:55:14Z"}, {"author": "Daniel Gillmor", "text": "

nope, this draft is just \"here's how you should represent that an OpenPGP secret key is backed by a smartcard\" (that has never been formally specified)

", "time": "2024-03-19T23:56:49Z"}, {"author": "Daniel Gillmor", "text": "

the wire format details in there are deliberately simple

", "time": "2024-03-19T23:57:24Z"}, {"author": "Daniel Gillmor", "text": "

i agree with Stavros that re-merging sounds like busywork

", "time": "2024-03-19T23:58:39Z"}, {"author": "Mike Ounsworth", "text": "

(deleted)

", "time": "2024-03-20T00:03:16Z"}, {"author": "Daniel Gillmor", "text": "

Justus, can you propose language for the pqc draft that encourages any PQ/T encryption algorithm to use the same specific combiner structure?

", "time": "2024-03-20T00:10:30Z"}, {"author": "Daniel Gillmor", "text": "

because that seems relevant even if we don't split drafts -- someone else comes and does some other PQ/T algo later, they need that guidance.

", "time": "2024-03-20T00:11:43Z"}, {"author": "Justus Winter", "text": "

I can try!

", "time": "2024-03-20T00:12:03Z"}, {"author": "Daniel Gillmor", "text": "

thank you!

", "time": "2024-03-20T00:12:09Z"}, {"author": "Daniel Gillmor", "text": "

aren't the performance impacts of the final KDF tiny compared to the rest of the computation here?

", "time": "2024-03-20T00:15:23Z"}, {"author": "Falko Strenzke", "text": "

yes, will be neglible

", "time": "2024-03-20T00:15:58Z"}, {"author": "Mike Ounsworth", "text": "

Soooo .... we are haggling over how long the airplane wheels take to deploy as part of an overall LAX -> SYD flight?

", "time": "2024-03-20T00:17:21Z"}, {"author": "Daniel Gillmor", "text": "

ha ha right

", "time": "2024-03-20T00:18:03Z"}, {"author": "Quynh Dang", "text": "

Yes my DKG. HOwever, why waste if we know it a waste already.

", "time": "2024-03-20T00:19:03Z"}, {"author": "Daniel Gillmor", "text": "

with no hats on, i have to say that i'm not convinced that nested signatures actually work in OpenPGP. i'd love to see more analysis on that before we lean on the idea of nested signatures

", "time": "2024-03-20T00:22:38Z"}, {"author": "Mike Ounsworth", "text": "

Registering an algorithm codepoint with a notBefore date will 100% get ignored ... \"Ooo! Look! Codepoint!\"

", "time": "2024-03-20T00:22:51Z"}, {"author": "Daniel Huigens", "text": "

Yeah, we don't really have any support for nested signatures, other than perhaps taking a signed OpenPGP message and signing it as an entirely new message

", "time": "2024-03-20T00:24:24Z"}, {"author": "Daniel Gillmor", "text": "

that's like the layer above the application layer :/

", "time": "2024-03-20T00:24:45Z"}, {"author": "Mike Ounsworth", "text": "

That's a really good point that nested signatures don't work on detached or self-sig.

", "time": "2024-03-20T00:26:20Z"}, {"author": "Justus Winter", "text": "

Only Sequoia implements nested signatures, and we don't do it correctly... :/

", "time": "2024-03-20T00:27:12Z"}, {"author": "Daniel Gillmor", "text": "

there probably isn't a test for nested signatures because no one has proposed an interface to sop that would enable creation or consumption of nested signatures

", "time": "2024-03-20T00:27:23Z"}, {"author": "Daniel Gillmor", "text": "

i can't honestly imagine an addition to sop that doesn't make sop really ugly to handle nested sigs, but i'd be happy to review if someone really cares about nested sigs.

", "time": "2024-03-20T00:28:34Z"}, {"author": "Daniel Gillmor", "text": "

but i'd also be happy to just declare nested signatures a deprecated misfeature in OpenPGP and leave it in the rearview mirror

", "time": "2024-03-20T00:29:01Z"}, {"author": "Daniel Huigens", "text": "

:+1:

", "time": "2024-03-20T00:29:26Z"}, {"author": "Stephen Farrell", "text": "

so we have both non-sep and sep at once:-)

", "time": "2024-03-20T00:30:41Z"}, {"author": "Mike Ounsworth", "text": "

@Aron Wussler These two sentences seem contradictory:

\n
\n

The signer can sign twice and distribute two keys
\nand the verifier needs just one of them to verify a signature,

\n
\n

and

\n
\n

Security guarantee: Strong non-separability.

\n
\n

Maybe I don't understand what the first sentence means.

", "time": "2024-03-20T00:31:02Z"}, {"author": "Justus Winter", "text": "

the two signatures and certs are: pure ecc and ecc/pq hybrid

", "time": "2024-03-20T00:31:49Z"}, {"author": "Daniel Gillmor", "text": "

mike, one of the \"keys\" is a composite of two keys. that signature has internal non-separability

", "time": "2024-03-20T00:31:52Z"}, {"author": "Justus Winter", "text": "

i know a lot of people using an authentication subkey to authenticate against ssh servers

", "time": "2024-03-20T00:32:58Z"}, {"author": "Justus Winter", "text": "

me included

", "time": "2024-03-20T00:33:02Z"}, {"author": "John Gray", "text": "

Open 3 has what I call protocol backwards compatibility. Its just a new signature algorithm, nothing else has to change. Complexity is in the crypto layer, and no ambiguity with verification.

", "time": "2024-03-20T00:33:06Z"}, {"author": "Daniel Gillmor", "text": "

i do it also (OpenPGP subkey for ssh auth)

", "time": "2024-03-20T00:33:16Z"}, {"author": "John Gray", "text": "

I meant option 3...

", "time": "2024-03-20T00:33:17Z"}, {"author": "Mike Ounsworth", "text": "

John Gray said:

\n
\n

Open 3 has what I call protocol backwards compatibility. Its just a new signature algorithm, nothing else has to change. Complexity is in the crypto layer, and no ambiguity with verification.

\n
\n

+1
\nAnd also has the potential to be a re-usable crypto primitive across OpenPGP, JOSE / COSE, LAMPS (if we do it properly).

", "time": "2024-03-20T00:33:56Z"}, {"author": "Daniel Gillmor", "text": "

as a library implementer (contributing to PGPy), i also don't object to containing that complexity within the OpenPGP library.

", "time": "2024-03-20T00:34:13Z"}, {"author": "Mike Ounsworth", "text": "
\n

\"Signature validation policy (AND vs OR) should be up to the consumer.\"

\n
\n

A counter-example to that is non-repudiation cases where a signer will want to say \"I will stand behind the validity of this signature only if ____\"

", "time": "2024-03-20T00:36:59Z"}, {"author": "Britta Hale", "text": "

The single / both key compromise is not different between the approaches (unless allowing forgeries under just one ... but then there are two different messages?). Is this meant talk about stripping effects instead?

", "time": "2024-03-20T00:37:24Z"}, {"author": "Stephen Farrell", "text": "

Non-repudiation requires lots more than sigs though

", "time": "2024-03-20T00:37:36Z"}, {"author": "John Gray", "text": "

I've been using composite signatures for close to 4 years now. They are not difficult to implement, and are easier to use than multiple single signatures as high level protocol logic needs to change and is easily incompatible with other application layers. The keys used as composite need to be uniquely generated (just like any other key). So a lot of the negative feedback on composites is easily mitigated.

", "time": "2024-03-20T00:39:52Z"}, {"author": "Rich Salz", "text": "

Yeah, X509 \"nonRepudiation\" extension has proven itself to be so incredibly useful in the past couple of decades. NOT.

", "time": "2024-03-20T00:39:53Z"}, {"author": "Mike Ounsworth", "text": "

Rich Salz said:

\n
\n

Yeah, X509 \"nonRepudiation\" extension has proven itself to be so incredibly useful in the past couple of decades. NOT.

\n
\n

Where it's used, it's used. See: eIDAS. I don't which extenstion you're referring to though.

", "time": "2024-03-20T00:40:24Z"}, {"author": "Mike Ounsworth", "text": "

I tried to argue for SLH-DSA + ECC hybrids in LAMPS in March 2023, using the \"but there might be implementation bugs / CVEs\" argument, and that got thoroughly rejected. It would be weird for OpenPGP to make a different decision.

\n

https://mailarchive.ietf.org/arch/msg/spasm/OaEF4lU8N5xg88fMQoc9EuSchsc/

", "time": "2024-03-20T00:41:37Z"}, {"author": "John Gray", "text": "

+1 Mike. We took out the SLH-DSA + ECC composites out of our LAMPS draft last year.

", "time": "2024-03-20T00:42:43Z"}, {"author": "Daniel Gillmor", "text": "

djb seemed to be arguing for SLH-DSA+EdDSA hybrid sigs in cfrg recently (i don't have a link handy),

", "time": "2024-03-20T00:42:55Z"}, {"author": "Rich Salz", "text": "

I meant the nonRepudiation in the keyUsage extension, @Mike Ounsworth

", "time": "2024-03-20T00:44:02Z"}, {"author": "Britta Hale", "text": "

Mike Ounsworth said:

\n
\n

I tried to argue for SLH-DSA + ECC hybrids in LAMPS in March 2023, using the \"but there might be implementation bugs / CVEs\" argument, and that got thoroughly rejected. It would be weird for OpenPGP to make a different decision.

\n

https://mailarchive.ietf.org/arch/msg/spasm/OaEF4lU8N5xg88fMQoc9EuSchsc/

\n
\n

It may be a matter of concept maturity - the more people looking at this, the more realize functionality / security benefits (a classic case of being too early in an adoption cycle). It may be that LAMPS would have a different view a year later...

", "time": "2024-03-20T00:44:11Z"}, {"author": "Mike Ounsworth", "text": "

Rich Salz said:

\n
\n

I meant the nonRepudiation in the keyUsage extension, Mike Ounsworth

\n
\n

Ah. I would have expected the legally-binding signature stuff in eIDAS to use that KU, but I don't actually know offhand.

", "time": "2024-03-20T00:45:13Z"}, {"author": "Mike Ounsworth", "text": "

Although looking carefully at Aron's slides, he is actually not proposing SLH-DSA hybrids; only pure SLH-DSA.

", "time": "2024-03-20T00:46:36Z"}, {"author": "Daniel Gillmor", "text": "

that's right, SLH-DSA is proposed non-hybrid here

", "time": "2024-03-20T00:46:58Z"}, {"author": "Justus Winter", "text": "

we don't have limited code points

", "time": "2024-03-20T00:47:07Z"}, {"author": "Daniel Gillmor", "text": "

John, would you resent it if OpenPGP manages to make it to a smaller range of algorithms than LAMPS?

", "time": "2024-03-20T00:47:37Z"}, {"author": "Mike Ounsworth", "text": "

Daniel Gillmor said:

\n
\n

John, would you resent it if OpenPGP manages to make it to a smaller range of algorithms than LAMPS?

\n
\n

I wouldn't. OpenPGP doesn't have the same long tail of weird usecases that X.509 does. Makes sense to have a more focused set of functionality.

", "time": "2024-03-20T00:49:27Z"}, {"author": "Daniel Huigens", "text": "

I assume the question was meant about composite signatures?

", "time": "2024-03-20T00:49:52Z"}, {"author": "Justus Winter", "text": "

generally, OpenPGP does pre-hashing

", "time": "2024-03-20T00:52:35Z"}, {"author": "Daniel Huigens", "text": "

Yeah, just for the record again I'm not that concerned about conserving code points, just questioning whether we need all of these

", "time": "2024-03-20T00:57:23Z"}, {"author": "Daniel Gillmor", "text": "

as i count it, the algorithms in the \"altered proposal\" in aggregate would all fit in the experimental range.

", "time": "2024-03-20T00:58:53Z"}, {"author": "Falko Strenzke", "text": "

I think this set is already quite restricted for an algorithm with such challenging performance characteristics. time-memory-tradeoffs are really import in this case

", "time": "2024-03-20T00:59:17Z"}, {"author": "Tara Tarakiyee", "text": "

flashback to every time I've googled rsa vs dsa

", "time": "2024-03-20T00:59:34Z"}, {"author": "Daniel Huigens", "text": "

@Falko: I agree if we only have SLH-DSA, but ML-DSA also offers good tradeoffs, no?

", "time": "2024-03-20T01:00:07Z"}, {"author": "Falko Strenzke", "text": "

But the security guarantees of hash-based are better than any other algorithm (this is the common view, at least)

", "time": "2024-03-20T01:00:49Z"}, {"author": "Daniel Gillmor", "text": "

it's hybrid all the way down!

", "time": "2024-03-20T01:01:02Z"}, {"author": "John Gray", "text": "

+1 Falko

", "time": "2024-03-20T01:01:08Z"}, {"author": "John Gray", "text": "

Daniel, sure, if open PGP decided on a subset, that would probably be okay.

", "time": "2024-03-20T01:02:33Z"}, {"author": "Daniel Gillmor", "text": "

@Tara exactly!

", "time": "2024-03-20T01:02:33Z"}, {"author": "Daniel Huigens", "text": "

@Falko: Right, yeah. I guess it's a question of how much you trust ML-DSA + EdDSA. I would just say that for it to be broken, we need _both_ ML-DSA to be broken, _and_ a cryptographically relevant quantum computer to appear

", "time": "2024-03-20T01:02:38Z"}, {"author": "Daniel Huigens", "text": "

If you think both of those would happen soon, defining multiple variants of SLH-DSA makes sense, but otherwise, we could also do that later, if it seems to become more likely, perhaps?

", "time": "2024-03-20T01:03:53Z"}, {"author": "Britta Hale", "text": "

Well, whether it is broken also depends on how they are combined. If these are parallel sigs, then it just takes a problem with one. So, that is a case of whether the combiner design is ensuring an AND or OR.

", "time": "2024-03-20T01:04:12Z"}, {"author": "Kris Kwiatkowski", "text": "

+1 Falko.

", "time": "2024-03-20T01:04:19Z"}, {"author": "Daniel Huigens", "text": "

Yeah, I'm thinking in the context of composite signatures, i.e. AND

", "time": "2024-03-20T01:04:34Z"}, {"author": "Falko Strenzke", "text": "

@Daniel: If the PQ era starts soon, then we have only one algorithm left.

", "time": "2024-03-20T01:04:47Z"}, {"author": "Daniel Gillmor", "text": "

yes, composite sigs are AND

", "time": "2024-03-20T01:04:48Z"}, {"author": "Falko Strenzke", "text": "

In the composites I mean. I think the preference for Hash-based for long-term security applications (firmware signing etc) is very common

", "time": "2024-03-20T01:05:34Z"}, {"author": "Daniel Gillmor", "text": "

Justus can you explain that test?

", "time": "2024-03-20T01:07:12Z"}, {"author": "Daniel Huigens", "text": "

@Falko: Right, yeah. I mean I understand that preference, again I'm just trying to question if we need all the variants. Maybe for code signing size and performance aren't as critical, and we could just only have the most secure one?

", "time": "2024-03-20T01:07:44Z"}, {"author": "Mike Ounsworth", "text": "

I agree with that. Code-signing usecases tend to not care about size at all (the thing you're signing is already large). But long-term security and signing time (ie throughput on busy build servers) and verification time do matter.

", "time": "2024-03-20T01:08:47Z"}, {"author": "Daniel Gillmor", "text": "

falko, it sounds like the sop wrapper for rnp isn't calling the api calls that rnp should use. can you open an issue about that with rnp-sop

", "time": "2024-03-20T01:11:30Z"}, {"author": "Falko Strenzke", "text": "

@DKG: OK, I make a note for that

", "time": "2024-03-20T01:11:59Z"}, {"author": "Daniel Gillmor", "text": "

thank you!

", "time": "2024-03-20T01:12:06Z"}, {"author": "Daniel Huigens", "text": "

I think it would make more sense for rnp-sop to keep the default behavior of rnp, no? Especially if these test results reflect how applications using rnp would most likely behave

", "time": "2024-03-20T01:12:40Z"}, {"author": "Daniel Gillmor", "text": "

daniel, maybe you can follow up on whatever issue falko opens

", "time": "2024-03-20T01:13:07Z"}, {"author": "Falko Strenzke", "text": "

@Daniel: But I wouldn't be sure that we can limit SLH-DSA use to code signing only. But let's continue the discussion on the list.

", "time": "2024-03-20T01:13:39Z"}, {"author": "Daniel Huigens", "text": "

Alrighty :+1:

", "time": "2024-03-20T01:14:10Z"}, {"author": "Stephan Ehlen", "text": "

I think for the transition to PQC it seems very reasonable to allow this situation and it seems like not allowing it would be a showstopper -- but I also think that the user should be \"warned\" in this case.

", "time": "2024-03-20T01:20:09Z"}, {"author": "Mike Ounsworth", "text": "

Can someone please summarize for the notes what was Aron / Justus' proposed path forward to not fail in this case?

", "time": "2024-03-20T01:20:58Z"}, {"author": "Stephen Farrell", "text": "

that's too long a question setup for a poll anyway:-)

", "time": "2024-03-20T01:21:07Z"}, {"author": "Stephen Farrell", "text": "

@mike: we will

", "time": "2024-03-20T01:21:20Z"}, {"author": "Britta Hale", "text": "

Yes, \"warning\" the sender as well as recipients to the greatest extent possible is important if this is allowed.

", "time": "2024-03-20T01:21:24Z"}, {"author": "Aron Wussler", "text": "

Stephan Ehlen said:

\n
\n

I think for the transition to PQC it seems very reasonable to allow this situation and it seems like not allowing it would be a showstopper -- but I also think that the user should be \"warned\" in this case.

\n
\n

I would be happy with a \"SHOULD warn\" in this case

", "time": "2024-03-20T01:21:27Z"}, {"author": "Stephan Ehlen", "text": "

+1 on also warning the sender!

", "time": "2024-03-20T01:23:24Z"}, {"author": "Stephan Ehlen", "text": "

recipient...

", "time": "2024-03-20T01:23:33Z"}, {"author": "Daniel Huigens", "text": "

@Mike: The path forward is essentially to use \"v4 style\" encryption for when using a combination of v4 and v6 keys

", "time": "2024-03-20T01:23:34Z"}, {"author": "Daniel Huigens", "text": "

(And I also think that's reasonable)

", "time": "2024-03-20T01:23:52Z"}, {"author": "Justus Winter", "text": "
\n

Every subkey for a v4 primary key MUST be a v4 subkey.

\n
", "time": "2024-03-20T01:25:29Z"}, {"author": "Daniel Gillmor", "text": "

\"v6 and higher\"

", "time": "2024-03-20T01:26:27Z"}, {"author": "Daniel Huigens", "text": "

I think since this group \"doesn't know\" about v5, I think what we say about it is actually irrelevant and doesn't really matter, one way or another

", "time": "2024-03-20T01:27:00Z"}, {"author": "Daniel Huigens", "text": "

I.e. even if we write \"v6 and higher\", someone could still implement something similar for v5 and write it up in a different draft, or not, but just not claim to implement this specific document

", "time": "2024-03-20T01:28:16Z"}, {"author": "Daniel Gillmor", "text": "

+1 Daniel

", "time": "2024-03-20T01:29:34Z"}, {"author": "Daniel Huigens", "text": "

Thanks!

", "time": "2024-03-20T01:29:50Z"}]