Session Date/Time: 22 Jul 2026 09:30
[00:00:07] Steven: Alright, folks. I guess we're at time. If somebody wants to pull the door at the back, that'd be great. Thank you. So welcome to the open PGP working group session today. My name is Steven. My co chair is DKG. I don't know if you wanna pop up on video, DKG. He's remote this time. There he comes.
[00:00:28] DKG: Hello. Hey. I'm.
[00:00:31] Steven: Great. And I guess this is the first session, at least I've been in person with our our new esteemed AD. Chris is there. So that's Chris if you want to talk to the area director. Great. So we have kind of a short session today and kind of an overpacked agenda. So I think what we'll do is we might not get through all of all of the presentation talks, but we have the the working group drafts and Heiko's presentation, I guess. And then we'll see what else we get to. We might have to organize an interim meeting in September or something to catch up with the rest of the stuff. It's my fault for only asking for an error. Since the note well, I guess you've seen this a number of times this week. There's a whole bunch of policies that we have. There's a bunch of things that you should do, and we should behave well. So you you just take take time to get yourself familiar with this if need be. For in person, please join the MeetEcho Lite client, I guess, if you're here in person and so that you're signed into the room. And if you're oops. There we go. Went too far. If you wanna join the queue, then please just hit the button that says join the queue. If you're remote, you know, headsets, etcetera, etcetera are good. And our agenda for today is we have this last agenda bashing in a second. We have a couple of four working group drafts I have a quick chat about. And then I guess we'll move on to external secrets, which is Heiko's presentation. He's over there. And the other there are some other slides, and we'll get to them if if we can. Does anybody want to agenda bash? Not seeing anyone. I guess we'll move straight ahead then given what we haven't much time. And I think it's Andrew Europe. I'll pull up the slides in one second. Stop slides. I think you're muted, Andrew. You don't have that audio. What? We can't hear you, Andrew. Okay. That sounded like a I'll be back in a minute. So what we'll do is is the next one Andrew as well? Yep. The next one's Andrew as well? Okay. So we'll skip we'll just keep skipping till we get to somebody who's who's this. One here. So Stefan is Andrew's back. Are you do we have your audio, Eda? Nope. No. So so, Andrew, what we if you if you can kind of yeah. We'll skip ahead. Stefan, if you want to jump in.
[00:03:33] Stefan: Yeah. Of course. I can I can do that? Can you hear me?
[00:03:36] Steven: We can hear you fine. Do you wanna take slide control?
[00:03:43] Stefan: You should you should have Oh, yes. Okay. Apparently, I have it. Okay. Perfect. Thank you.
[00:03:47] Steven: Okay.
[00:03:47] Stefan: Yeah. Thank you thank you so much. So this is just a very quick update on the NIST and brain pool composites and open p g p. If the draft draft- ITF, OpenPGP, and NIST bp comp. And just a quick reminder, these are adding composites, combinations of ML-KEM and ML-DSA with the NIST and brain pool curves aiming for classical security, a 192 bits and two two hundred and fifty six bits of security. This has been unchanged for for a longer time, actually. There's been positive discussions on the on the mailing list. Everything has been stable in the draft so far. What has been missing previously was two independent implementations. We have them now. There's one in rnp and one in sequoia-pgp. I I believe the rnp one is already merged, but you have to, like, enable experimental flags to to to allow these. And in sequoia, I think we have a positive feedback on the on the merge requests, but these are two independent and interoperable implementations for the draft. It's a straightforward addition of code points to RFC 9980, adding PQ/C with the NIST rainbow curves. And we believe the draft is ready or has been ready for quite a while for working group last call. I would like to request working group last call from the working group. That's it from my side.
[00:05:27] Steven: Great. Thank you. Any questions or comments? Not seeing anything in the room or in the list. So I guess, good news on the limitations. So I guess we'll kick off a working group last call for that soon. Sound okay, DKG?
[00:05:47] DKG: Yes. Sounds good. Thanks for the persistence, and really glad to see that that we've got multiple things implementing. Great.
[00:05:57] Stefan: Thank you.
[00:05:59] Steven: Thank you. Andrew, you wanna try again or you he's gone. He's back. No. He's not back yet. So I guess we move on to PSK
[00:06:16] Daniel: and
[00:06:20] Steven: add the slide clicker. This should work for you.
[00:06:26] Daniel: I don't have a lot of slides, but yeah. So quick status update on Persistent Symmetric Keys. I won't repeat this presentation what it is since I've presented it here so many times. But we do have three implementations now. Yes. Two of which are independent. So two of them are by me, and one is by Heiko. Thanks for that. So we have so there's not a lot of pixels on this beamer. But you can at least see the green and the red, most mostly green, interrupt tests. So all of all of what's in the persistent symmetric keys draft is implemented by OpenPGP. Js, GoCrypto, and rpgp. And they interoperate fully. The red stuff you see on these interrupt tests is a SOP question. Because in order to use, persistent symmetric keys, with SOP, you need to be able to, well, use yeah. Obviously, persistent symmetric secret keys, so secret key material with sub encrypt and sub verify. And we also have now tests for using encrypted keys for those operations. So then you need to be able to pass a password as well through SOAP to to the OpenPGP library in order to use those keys. And that has not yet been specified. So, yeah, that is also still a bit up for discussion, how the integration with SOP should work, but I will make a merge request at some point with a proposal for that. And then we can have full full interrupt testing. Our implementations cheat a bit and implement it already even though it's not in the subspec yet. And that's how we, you know, were able to test in interoperability between those. So, yeah, we have a whole bunch of tests now in the in the interoperability test suite. Most of them work, and the the draft is essentially stable. As far as I know, there are no real open questions anymore. So, yeah, also here, I think we could go to working group last call.
[00:09:31] Steven: Great. Thanks, Any questions, comments? Looks like he has a comment.
[00:09:40] DKG: No. I'm just pre again, I'm happy to see the implementation progress and the interrupt testing. That's it's good to see. And we do need to get I think we should clarify how we want that in in SOP. I don't think that the SOP changes should prevent us from moving forward if we if we have demonstrated in Europe.
[00:10:00] Daniel: Thanks.
[00:10:00] Steven: Okay. So that sounds like another working group last call to tee up for the chairs, and we go from there. Thanks, Daniel.
[00:10:06] Daniel: Thank you.
[00:10:07] Steven: Okay. We'll try Andrew again. And we'll still hear some button clicking.
[00:10:11] Andrew: Hello. Hello.
[00:10:12] Steven: Yes. We can hear you now, Andrew. Great.
[00:10:14] Andrew: Yeah. My my years long war with Firefox continues.
[00:10:24] Steven: And they'll be nice.
[00:10:28] Andrew: So right. So okay. Quickly, the current state of the HKP draft. So this is just a quick overview of the design. We have a legacy API and a v two API. The v two API is much more restful than the legacy one. We have various changes to the way that HKP has traditionally worked, but we hope in a backwards compatible fashion. So the current status is that, the draft still doesn't have a, schemas for the JSON, parts of it. So, the the v two API is supposed to, return, JSON responses and, there are examples but they're not formally specified. And so the the question, at the moment is do I want to use JSON schema or since we're also talking about using structured mail, maybe JSON LD would be easier. I I I I don't have any any particular, dog in that fight because I'm not overly familiar with either of them. I'm coming to, you know, as a as a relative outsider. So if anybody has a suggestion for how best to do this, that would be great. The one thing about structured mail is that it is still work in progress and so we may not be able to use it as a normative reference if we want to get this done in our own time. So maybe JSON schema is is older and better understood and we just and we just don't try to align with with structured mail, because that's that's still that's still in flux. One thing that, I put in relatively recently into the draft, I can't remember if it's in the current the current published draft or if it's just in the editor's copy, I will make an update after IETF, Is this idea about a DKIM signed self addressed message as a authentication proof? This idea would be that in in order to have a non interactive proof of ownership of an email address, You could send an email to yourself, have your email provider automatically sign it with its DKIM key. And then for the lifetime of that DKIM key, this could act as a an offline verifiable proof. And it turns out that some a similar idea just went to dispatch on on Monday, and I've linked it here. The advantage of using DKIM is that most mail providers already have DKIM set up, whereas this one from Heart is a novel approach, but it might be worth including that as another option into the future. One issue with that is we could have too many options and it's it's might get out of hand, and maybe we should stick to one or two well understood methods. Steven?
[00:13:48] Steven: Yeah. Sorry. Just put myself in the queue. So can can you just outline the DKIM idea again? Sorry. I I kinda missed it. So you You did.
[00:13:57] Andrew: Sure. The the the DKIM idea is that in order for spam prevention, we want we want to be able to verify people's emails when when they upload key material to a key server. And the way that keys.compgp.org currently does it is you upload your key. It then sends a verification email to the user ID that's in that key. And then you click on a link in that and that goes back and confirms in in in KO. One of the issues with that is that since anybody can do the initial upload, it's then possible to generate these verification emails to be sent to somebody who isn't expecting them. So the way that we decided to do it in, HKP v two was to invert this and the idea would be that you would go to a well known URL, request a verification email and then use the token in that email with your submission to submit your key. That's interactive though and it also means there's there's email delivery issues potentially and spam copying and all and all of that. So the DKIM signature idea is that instead of getting the key server to send you an email, you send an email to yourself. And by sending the email to yourself, hopefully, your email provider has implemented DKIM. Vast, vast majority of people have because it's effectively a a requirement these days. And that DKIM signature is verifiable by anybody if they have a copy of the mail and the signature over it and the DKIM keys are published in the DNS. So a key server can take this email essentially as proof that you have successfully sent an email to yourself through your provider which provides the same security guarantees but is much more robust and less interactive. Does that make sense?
[00:15:58] Steven: I think so. Well yeah. Okay. Okay. Thanks. D k g?
[00:16:07] DKG: Yeah. I wanted to understand the not the the so so I I think I mentioned in the data in the issue tracker that I'm concerned about the DKIM because DKIM keys expire, and there needs to be a bit more guidance about how to think about that. My assumption will actually publish their secret keys for their DKIM signing to provide deniability, longer term deniability for messages. And so that might there might be a wrinkle there where, you know, you get a different view of what the Deacon key should be allowed. But but I also I also wanted to so, yeah, I'll I'll start with that.
[00:16:49] Andrew: Okay. So the so, like, DKIM is a transient security mechanism as you say. You know, the keys have a relatively or can have a relatively short timeline and they can be burned, as you say. So this would only be used to get the submission. But there were these this this proof would not be stored long term on the key server and then serve the clients. It's not part of the OpenPGP security model. It's just part of the API interface between the submitter and the and the key server. So once once the certificate has been successfully uploaded, well, that's that's the Deacon signature's job done and it can be discarded shortly thereafter. And generally, what will happen is if somebody has burned their DKIM key, they're not going to so if they publish their secret key, there that will be a significant time after they have stopped publishing the corresponding public key in the DNS because if you overlap those, then there's an overlap where somebody can can forge your emails. So once the once the lifetime of the public key public DKIM key has expired, well, yes, then then any DKIM proof, it's no longer verifiable, it's no longer useful. So by the time you come to actually burning the, like, the n minus one Deacon key, it's all it's all useless anyway.
[00:18:26] DKG: Okay. So I'm I I I think we should if we're gonna include this, we need some guidance both to the to the server operator about, you know, ensuring that they have a fresh view of the DNS that the Deacon signature is right? For the Deacon selector. Right?
[00:18:44] Andrew: Yeah. And I I think we I think we should just be able to reference the the DEACHEM spec itself because DEACHEM will already have that guidance.
[00:18:54] DKG: Well, DEACHEM is designed to think about pretty much at delivery time, and there's no this is no longer SMTP delivery. The the other
[00:19:01] Andrew: It is a delivery format, though. It's not over SMTP. It's over HKP, but it is if you think of submission time as being delivery time, it's verified once at the point of submission, and, you know, after that, it's not
[00:19:15] DKG: it's not used. So We also probably want some guidance for clients that are doing this, about, that they should you know, that it needs to be a fresh message. Right? Like, can't send myself a message and then use it, two weeks from now if I don't know what my provider Fair. Signing policy is.
[00:19:35] Andrew: Yes. Fair. Yeah.
[00:19:37] DKG: So my my other question has to do with the the prove then submit, approach, which you motivated by saying the problem with the submission, submit then prove was that it would generate, you know, it could be used by someone to generate spam messages from the service. But how does prove then submit avoid that? Can't I just go and, can I go to prove and have it generate, tokens by email and spam arbitrary people that way too?
[00:20:15] Andrew: Yes. Yes. You can. But the the point is it's it's more difficult to do it by accident, you know, because traditionally, when you're uploading something via HKP, the clients already have that built in. They'll encourage you to do things or or they won't prevent you from doing it. So if I have your your certificate, I can just push it up and upload it to k o o or or wherever right now, and that could generate a verification email to you. Whereas with prove then submit, you have to be more intentional about it. It's you know, so so, yeah, you can still abuse it, but you have to abuse it deliberately, whereas and there have been cases of people complaining to KOO about, I got this verification email from you, but I didn't upload my my key. What's going on here? It's like, well, yeah. Some somebody else uploaded your key. Tough. You know, this does not there's not much we can do, and and prove then submit avoids avoids that confusion.
[00:21:13] Steven: K. We have Daniel in queue.
[00:21:14] Daniel: So my I originally proposed it to KOO with the motivation of handling certificate bundles that have potentially multiple certificates, which could have theoretically different user IDs and so on. So part of the reasoning was also just to make it more clear which email address you're trying to upload a certificate bundle for. So by requiring to specify that upfront. So you say, here's the email address, then you give a certificate bundle that may have multiple certificates and maybe user IDs, but it then it's clear which email address you're uploading the certificates for rather than the server having to extract the user IDs from all the different certificates and then having to guess what you want to upload or update for which email addresses.
[00:22:23] Steven: Okay. And then there was this hard to email proposal in at the dispatch session. Was there a side meeting after that about that or something afterwards? Was anybody at that? Yes. You do can I just tell can you tell us at the mic, Daniel, what happened? Or Yeah. If you got the mic, sir.
[00:22:42] Daniel: Sorry. Yeah. So there was a side meeting. It was half of it was a demo showing how the thing worked, and then there was some discussion about the technical details, and there was some discussion about what's the overlap with OAuth, and do we really need a new mechanism here? I don't think a conclusion was reached. I I generally like the idea. Then there was also discussion about private email addresses, and there is this mechanism in there about revealing those or handling those that I personally don't like. But that I think is a bit besides the point here. But, yeah, it seems that there are people interested in implementing that, and there there is an implementation there by by Google and some other parties.
[00:23:42] Steven: Okay. So so it sounds like that that topic of authentication via DKIM or via something else is one to to keep an eye on and and do a bit more work on. Yeah. Great. Thank you. Okay. Andrew, off you go.
[00:23:54] Andrew: Yeah. Sorry. Time is up, but I will rattle through the rest of this. Some recent open questions. Well, one not recent and one more recent. So there was a there was a significant discussion in mailmaint in yesterday about whether or not well known paths are required. So that that's something that we've we've come back to a couple of times. I think since the argument mailmaint and the argument for HKP v one or legacy HKP is that some things have been specified without a well known, for ten, twenty, sometimes thirty years now, and, we can't just, you know, stop using the the the existing hard coded paths. But, HTTP, they're are quite keen that people should migrate away. So that opens the question of whether we need to specify a well known path as, like an optional update or, for for v two only or or something like that. That's that's an open question. The other, open question for me is, serve records. So we the draft currently specifies serve records for key discovery using the open p g p key service name, which matches the use of open p g p key as a string in various other places for, like like, WKT, for example. But in previous versions of the draft, we also specified the use of serve records just to find the address of a public key server like keys.openpgp.org. And that was removed partly because we we didn't think it was actually strictly necessary. Subsequently, it's become clear that several clients have actually already implemented this and have implemented them for years, but they use a different service name for the serve record. So we specified in the draft, Daphne in particular specified in the very first draft, the use of hkp.tcp. Domain. And subsequently to that, people started using pgpkeyhttp. Under tcp.domain. Seemingly, I'd say, as some some kind of parallel evolution. And so the question then is how do we reconcile this? Do we want to reconcile this? Do we want to do it in this draft? But that's something that I haven't spent too much time thinking about yet. I will take it to the list.
[00:26:38] Heiko: Good.
[00:26:40] Andrew: So current status, hockey puck is nearly done. Hagrid is not nearly done, and clients there's there's no explicit client support, but you can test it using curl. It's a really, really straightforward API. So thank you.
[00:26:58] Steven: Great. Any other comments on that? If not, we'll move on back to Andrew again. Think it's you, isn't it?
[00:27:14] Andrew: What's this replacement key?
[00:27:15] Steven: I guess.
[00:27:18] Andrew: It is. Okay. I don't have control yet. Okay. Cool. Yeah. So, I will be really, really quick about replacement key. Basically, there have been very, very few changes since, the last IETF. The the basic design is here. I won't go through it again. The slides are online. The current status is the wire format is stable. It has not changed in nine months, twelve months, I think, at this stage. We have a mature draft text. We have examples. We have test vectors. The big change since the last time I spoke is that we now have two interoperating library implementations. Now these are quite low level, but there's one in gocrypto written by me. There is one in rpgp written by Heiko. And we can we can parse each other's artifacts. The testing has been manual at this stage. It hasn't been supported in at any at the application layer anywhere, and there's absolutely no sign of any API for doing this in in SOP, for example. So we we haven't been able to get this into the interop suite. There's a lot of there's there's a lot of hoops to be jumped through before we get to that stage. But certainly at the at the wire format level and the library level, it is stable. It is interoperating. So interoperability in SOP is is really the thing that might be blocking. So over in the in the SOP repo, there are a couple of merge requests. There's no real consensus about how to proceed. So more discussion and more opinions on those, I think, will be necessary. So I will take this to the list again and prompt people to please think about how this should be exposed at the stop there. And that is it.
[00:29:38] Steven: Great. Good to see it's moving along. Good to see it get get further. So any comments or questions on replacement key? Not as of now. Thank you, Andrew. Okay. We're rattling through these nicely. Let's see what's next. Done that. Done that. Done that. Heiko? So we may get through more of our presentations than I thought. The clicker should, oops, shortly work.
[00:30:19] Heiko: Hello. I'm Heiko. This is a very simple draft about a problem that has, as far as I know, currently no solution, namely, you have a hardware device that contains secret key material, and you'd like to use it with applications interoperability. And this is one proposal for how to do it. The idea is, as I just said, you have the secret key material and you want to have some interoperable way to tell an application, like, I want this key to be used from some place that is not on the host computer, but maybe on a USB device or over the network or whatever it is. This draft proposes a way to do this by defining a new a code point for the S2K usage, which normally says, how is the secret key material encoded in terms of is it encrypted? Is it plain text? And this one would just say, I don't have the secret key material. Go find it elsewhere. And then there's an optional hint that clarifies where that elsewhere might be for this key. But this draft doesn't really outline a whole lot about that mechanism because it's currently unclear if that's even needed by anyone and can be specified later. The status of the draft is there are test vectors both for v6 and v4 TS_K that use that scheme. There's an experimental implementation immediately to be that I've written. And I think to progress on this, adoption would be needed to get a good point.
[00:31:50] Steven: Okay. Any questions or comments interest in this? So I I do have one question. So this this is kinda reminiscent of some smart card API stuff as well, is it?
[00:32:02] Heiko: So does that by putting some experimental code point in that place, and this is essentially saying, hey. How about we specify a real code point?
[00:32:10] Steven: Right. Okay. Good.
[00:32:11] Heiko: So this is telling the application, you have a secret key, but there's no actual secret key material in it. Like, go do something.
[00:32:19] Steven: Okay. Any questions or comments? We have one. Andrew?
[00:32:28] Andrew: Hi. Yeah. So so my understanding is that GnuPg does this by using an experimental code point in a different registry. So it's not the S2K usage Right. Registry, it's the other S2K registry and but the idea is I think that this draft uses the S2K usage registry because it's actually a more a more logical place to put it.
[00:33:04] Steven: Okay. So I guess this is a case of the list, see if I mean, I don't I don't see anybody here. Does anybody here think that this is something they'd like to implement, or does anybody here think this is terrible? Go to the mic if in in either case. Thank you.
[00:33:27] DKG: So this is Daniel speaking not as a chair, but as one of the coauthors on this. Oh, sorry. There's someone in person. I'll defer to you in person there. I didn't see you in the queue.
[00:33:39] Steven: Okay. Go ahead.
[00:33:40] Krishna: Yeah. But most of my implementations, I actually stopped keeping my own things, but building on top of HEICO's work. But this is something I'm always, like, extra looking forward to because all of my use cases, the secrets has to be on HSM or some external devices. So I'll be looking forward to actually implement and see how how far I can reach and as an application maintainer.
[00:34:08] Steven: That's that's that's great to know. Thank you.
[00:34:10] Stefan: Thank you.
[00:34:10] Steven: Good. And, back to you, I guess.
[00:34:14] DKG: Yeah. Thank you, Krishna. So I think this is a very simple proposed mechanism. It is not actually super complicated. It leaves room for folks to do something a little bit fancier if they want to with the location hint. I actually don't think the location hints are needed, but it it carves out space for folks who wanna do that and gives guidance about that you shouldn't you know, if you can't find it via the hint, you should still try best effort anyway. I think, you know, I actually don't think that depending on smart cards, is a net win. But I think if you're gonna be if you're gonna do it, which I know people wanna do, we should have a clear way to do it. And I think this is a relatively simple, proposal. So I would I would be happy to see this move forward just because I think, you know, allocates a code point in the registry, and and then there's pretty clear guidance on how to use it. So I I would like to see it done if we can.
[00:35:18] Steven: Great. So so I guess we'll follow-up with some call for adoption or something on the list. But if you if you wanna meantime, I think if you wanna pop a mail to the list, see if there's yet more interest, there's there's obviously some. That's no harm. And maybe we'll get the working class calls and the other things out of the way for us to then put a call for adoption after this.
[00:35:34] Heiko: Sounds good.
[00:35:34] Steven: Great. Thank you, Heiko. Takes back control of slides, and we're getting through loads of these. Great. Okay. So which is next? I've lost track. AutoCrypt. Should we do that one next? Feel feel free to chime in if I'm putting things in the wrong order.
[00:36:00] DKG: No. This is fine. I'll this is this is work by myself and sorry. I'm trying to set up the timer for myself, and it's it's not working here. There we go. Yeah. So this is work by myself and some other folks who have done auto cook work, in particular, Holger and Friedel. This is a open p g p certificate profile. We are not currently asking for working group adoption on this because we wanna get some experience with it in the wild. We're using existing open p g p specifications. And we just say this is how a particular type of open p g p certificate will work. It has a standard Ed25519 primary key. It's all v six. It has a fallback encryption subkey, which is using the the post quantum spec. And it that callback subkey does not expire, and then it has a rotating subkey that does expire. And that rotating subkey is replaced on a regular basis. So I'm gonna get into a little bit about why we do it that way. But you're gonna see, certificates like this in the wild at some point. And so we would just wanna give a heads up to folks in the OpenPGP world about the fact that this is happening. It's all using existing OpenPGP specifications, and it may have some downstream implications. So it's worth thinking about. So it's using post quantum keys for encryption. It defends against harvest now, decrypt later attacks. It offers a form of reliable deletion, which is what I've been calling people often use the term forward secrecy, which I don't think is a good fit for messaging systems because your message archive actually contains things that need to be deleted if you want forward secrecy. But the idea is that, you know, traditional OpenPGP messages, if they are stored and someone gains control of your secret key material in the future, they can decrypt the key even if you've deleted every copy of it you ever had. If they were just copied in transit, you've you've lost the ability to reliably delete them. This uses deterministically ratcheted sub keys. So that rotating sub key gets ratcheted forwards on a time basis. And then once you have rotated that subkey out of the way and destroyed your old copy, then copies of the message that were encrypted to that subkey can be, can't be recovered, by an adversary who does this key exfiltration attack in the future. So it offers the effect effectively some form of reliable deletion that open p g p has never offered before using existing specifications that only that that has been in open p g p for years. The other wrinkle in the certificate is it tries to do minimal metadata, so that has no user IDs, and it actually uses a fixed key creation timestamp for the primary key and the, and the fallback subkey. It does that specifically so that it doesn't leak information about when the key was, created. That's a piece of information that people can find useful to track, to to track a user. And so it just reduces that. So the peers only need to know about RFC 9580 and RFC 9980. And they should be able to use this sort of as is without knowing about these details. The key holder, that is the person who holds the secret key material, also needs the ratcheting logic to be able to use it safely. There are at least two implementations in progress, might be three. And we have test vectors in the draft, so you could try it, see how it works with your implementation. This is you know, I've got the diagram of how we do the ratcheting. I'm not gonna go into the details here. But if somebody with a better cryptographic mind than I have wants to review it and tell me what we're doing wrong with the ratcheting, that would be great. I think it's okay. But, you know, we're presenting it because we want people to understand and give us a review. The the the motivation for this temporal ratcheting instead of per message ratcheting is that it allows a user to have multiple mail user agents that use the same secret key material and not need to synchronize their cryptographic state with one another as long as they've got their clocks synchronized. So, yes, it requires clock synchronization, but we the the the hypothesis here is that is a much simpler problem than complex cryptographic state, synchronization. And so you can use the secret key material to transfer it from one device to another, and then you can just use it going forward and, without having to make sure you have some active sync between those agents. And that like I said, it offers its reliable message deletion, property, which doesn't act it doesn't get us all the way to reliable message deletion because, obviously, to do reliable deletion, you have to actually make sure that your archive deletes things. But it prevents the leak based on the keys themselves. I see, Scott, you're in the queue. Or you're just queuing up for the
[00:41:18] Steven: He's on the right.
[00:41:20] Scott: Great. Quick question. I just glanced at the ratcheting mechanism and it the stateholder system. I just I'll glance at the ratcheting mechanism and it appears that you're using some of the properties of x two of elliptic curves. And it would not translate to say ML-KEM.
[00:41:41] Andrew: Is that correct?
[00:41:43] DKG: The ratcheting so the key that's being ratcheted is one of these hybrid keys. It's a it's a it's a two fifty five nineteen and ML-KEM combined. And so the there is something to do with X25519 because when you do the ratchet, you get a you get a high entropy blob out of it. And from that high entropy blob, you have to derive your ML-KEM key and your X25519 key to build the new hybrid. And so, yes, there's a does that make sense?
[00:42:12] Scott: So you compute you compute a new you you re rerun the ML-KEM key generation algorithm using your new seed?
[00:42:22] DKG: Yes. That's right.
[00:42:23] Scott: Okay. That's fine. Never mind.
[00:42:25] DKG: Great. Thank you for the for the if you wanna do a deeper review than than the first glance, I would love to hear that from you as well. So I appreciate the flag. So yeah. So this is so so this doesn't come give you complete reliable message deletion because it we're not saying anything about how you handle the archive. That's work for the implementer. But it does prevent, message recovery based on, you know, harvest now decrypt later or harvest sorry. Based on harvest now and then, exfiltrate keys later. So, we think this this works. It seems to be pretty simple. It was pretty straightforward to implement, and it's using existing specs. So a couple of wrinkles to note for the broader ecosystem. The not everyone agrees when you see an open PGP certificate with multiple encryption capable sub keys, which one to use. This one says you'll get the reliable deletion if people only encrypt to the rotating sub key while while they have it. The fallback sub key is there because you might not get your peer might not get a refresh certificate, and then the rotating subkey falls out of his expiration date. If they encrypt to that rotating subkey, you won't be able to decrypt it in the future. So you need a way to be able to handle that, that sort of, failed certificate refresh scenario. But if clients just encrypt to all encryption capable subkeys, then you won't get the reliable deletion property. So, there is some question about how your peers interact with this to achieve reliable deletion. It fails gracefully it falls back gracefully to you just don't get reliable deletion. You still get the confidentiality. But, it it's made very clear to me, that that this is a gap in the open p g p ecosystem. We have not decided successfully how to, there's no consensus on how to do encryption subkey selection. So this draft proposes a way to do it, but doesn't require it. And with the consequence that if you don't follow the proposal here, then you don't get the reliable message deletion. It's also possible that these certificates will grow without bound because the number of encryption capable subkeys will, add up. And so this draft says, hey, if you see an expired encryption capable subkey, you should probably throw it away because you don't want it to just grow forever. But not everyone does that today. So if you expect to keep around every encryption capable subkey that you've ever seen for a given, certificate, you might be surprised, to find your certificate store growing if you're doing regular certificate refresh. And like I said, you know, if the if the if the peer doesn't can't refresh certificate, then we fall back to nonreliable deletion. So the draft is being worked on at this repository. Again, we're not asking for a working group adoption at the moment. We just wanna get the message out there so that folks in the ecosystem know that it's going on. And I think that's it. If folks have questions, I'd be happy to hear them. And we would, you know, love any kind of review or or comment either on the mailing list or in the repo here, has a issue tracker associated with it.
[00:45:40] Steven: Great. Thanks. Any questions or comments there? Don't see anybody in the queue. Thanks for timing yourself accurately, Okay. So I guess that's you're not asking you're not asking for adoption. Using the open PGP list for discussion is probably reasonable for this. And the other venue for discussion is then on the Git repo, I guess, or code or whatever it is. Great. Okay. Nothing else on that. Andrew, do you wanna pick grease or holes?
[00:46:17] Andrew: I'll I'll try and do both quickly if if there's time.
[00:46:21] Steven: Okay. Well, actually, we start with Greece.
[00:46:25] Andrew: Okay. So GREASE is is relatively simple. It it's an idea that comes from TLS, but I have since learned that it has been proposed in a few other places including IPSec. So the idea is that there are a few code points that are reserved in the registries that you want to test and production systems can generate fake artifacts using these code points. The idea behind this is that traditionally, OpenPGP in particular has been very bad at doing forward compatibility. So one of the things that the interop test suite does is it generates artifacts with, you know, future version numbers and future sub packet IDs and so on. Greece would be a formalization of this process to allow other software in production to do this outside of the sandbox of of the interop suite. And one place where this could be done is on the key servers. So the idea would be that if you are serving, if you are serving a key, a certificate, you could add, for example, a fake subkey with, you know, with with a weird algorithm and see whether this breaks plants. The the idea so the idea would be that this would be introduced on a phased basis. It would only be introduced in new protocols. So the reason that I'm bringing it up now is because I'd like to be able to do this in HKP v two. So doing it in HKP v one would break half the Internet and as absolutely out of the question. But doing it in HKP v two and doing it from the start in HKP v two would mean that we would discover interoperability problems in production in the wild very quickly. So what we do what we propose to do in in this draft is there are eight code points that are not used currently in any of the registries. So this draft reserves them in every registry just just just across all all of them. But all the registries that have single octet code points, there are some registries where obviously this just just, you know, wouldn't be applicable. But wherever applicable, these code points would be reserved for grease usage. It also, in a little drive by, it also expands the private experimental ranges to 16 code points instead of 11. This aligns to a nibble boundary and it simplifies the process of detecting, experimental code points in in code. You would notice in, if you were looking at the, Heiko's presentation, the the draft that he was talking about, it actually uses experimental code points, aligned to this boundary already. So so the draft is is there. It is relatively short and sweet and simple. It does not currently, contain specific guidance about when to apply grease to objects in production. However, there is actually a draft that I, DKG brought me, brought to my attention just yesterday, I think it was, where they are trying to formalize the best practice. There's an informational draft for how to use grease and other protocols. So, we would attempt to align with that wherever possible. I didn't get the time to add the link to the the slides, but, I'll I'll I'll drop it into the chat or into the mailing list as soon as I dig up the reference. Thank you. D p g?
[00:50:51] DKG: Yeah. Thanks for this. I think this is interesting work, I've I've it seems like it would not be too hard to, get a consensus on this if we're okay with, you know, burning these code points, for actual use. I think that the interoperability would be worth it. I was wondering if you had any thoughts about how we should grease the, bit flag registries. We have at least two bit flag registries that I am aware of in open p g c. So like key usage flags, for example. And I wonder if you thought about whether we can do that there.
[00:51:30] Andrew: I so yes. We we we could reserve a bit in, like, the second or third octets in one of those registries. Yeah. Maybe second bit in the second octet, third bit in the third octet, something like that. It could be possible. Yeah. We just have to be careful that when it is used, it is only used in scenarios where a receiving implementation is expected to fail gracefully. There are some cases I'm trying to I'm trying I I can't think of all the bit flags off the top of my head. I would just be worried that maybe one of them would be a feel hard rather than a feel gracefully scenario, but yes, it could it could be done in principle. Yep.
[00:52:24] DKG: Okay. I'll open an issue in the repo that's tracking this to suggest it and Great. See if comes from there. Thanks.
[00:52:34] Steven: Great. Okay. Any other reaction? Anybody think this is a terrible idea, a good idea? Seems to have come gone down as a good idea in other protocols. So I guess we'll track along and at some point have a call for adoption type thing. And, Andrew, yeah, in a while?
[00:52:57] Andrew: Yep.
[00:52:59] Steven: K. So back to Andrew.
[00:53:05] Andrew: Alright. Yeah. Maybe it's better that this one is last. This is the one that generates lots of wheeling and gnashing of teeth. So we have we have a long standing issue in OpenPGP about creation times and how to treat creation times. And at the moment, several implementations overload the the meaning of creation times, particularly the signature creation time. So the signature creation time is used both to order signatures so that you know which one is latest and therefore which one is most recent and therefore the one that is currently enforced. But also, you know, many implementations also treat this as a not valid before flag, which is a subtly different concept. If you go and dig way way way back down into the into the discussions around RFC two four forty back in the mailing list, you'll actually find that one of the initial concept of signature creation time was that it would not be used as a as a not before, not valid before. It's actually the the the key creation time or sub key creation time would be used as the not valid before, timestamp. This language did not make it into any of the final RFCs and as a result, there's been a lot of confusion since as to, you know, what exactly we should use as not valid before. So for example, GnuPg does it one way, OpenPgpjs does it another way. And and what ended up happening was that one of those interpretations was coded into the interop suite as as a a test that contributed to the score. And then gamification takes over and people want to bump their scores so they follow what the interop suite does. And essentially, what this has done is it's it's it's hard coded into a lot of people's expectations, something that isn't actually in any of the RFCs and which might actually be a suboptimal interpretation. The implications of this are that, if you're verifying historical signatures, you also have to keep around all the all the historical self signatures, because otherwise, your your objects may not have been valid at the time or at least within your within with from from your implementations point of view, the objects may not have been valid to create signatures at that time. So you get you get a lot of problems with, things either becoming unverifiable or growing without bond over time and being unable to to clean up. And the stateless OpenPGP is potentially a huge problem there because they are huge. Heiko?
[00:56:08] Heiko: I just wanted to push back very quickly against you implied that the test suite sorry. Oh, sorry. Heiko Schafer. You implied that the test suite caused everyone to implement one thing, and I don't think that is true. I think the test suite caused everyone to implement something with different semantics that kind of that makes stuff go green, but doesn't actually do the same thing in all other cases. So just pushing back against what caused everyone to do one thing.
[00:56:36] Andrew: Yeah. I I may have oversimplified things slightly. But yes. Daniel?
[00:56:49] Daniel: Yeah. It's also I you you already know this. But just to be explicit and clarify a bit, the the not before interpretation that our implementations have is is about the validity of the signature, not the validity of the key. So if you have multiple self signatures with different creation times, then each of those signatures can be valid, and the the key can be valid for the whole time range. So if you create a new self signature with the new creation time that doesn't update the the start of the validity period of the key as a whole. So in that sense, it's not the same as not before, like, as in how it will work in TLS or something like that. But it's true that we need a valid self signature in our implementations. So then if you go and throw away the old self signatures, then that is potentially relevant for old artifacts unless you keep the creation timestamp the same.
[00:58:10] Andrew: Yeah. Thanks, Daniel. That that is what I intended to say. Possibly, I'm not not I wasn't again, I wasn't quite clear for the because I'm I'm trying to rattle through as as fast as possible. D k g, are you back in the queue? Or
[00:58:27] DKG: Yeah. I'm back in the queue. It occurs to me that Daniel's interpretation, which is slightly different than the than the interpretation about, you know, just key validity itself, might be relevant for things like key usage flags. So I might wanna say I've got a signing capable subkey, and I wanna know is this signing capable subkey, was it valid for a signature at time t? And the most recent signature I've got is at time t plus n. And it says the the subkey flags are at, you know, are signing capable. But I don't know whether an older subkey an older signature indicated that the subkey so in some sense, it's actually saying I think, Andrew, the Hole-Free Validity that you're arguing for says, not only does this mean that the key was valid from key creation time until my the signature expiration, but that all of the sub packets that I have should be applied to that key for that entire window as well. So I sorry. I realized we're out of time. But if if there's any interesting wrinkle there.
[00:59:30] Andrew: Yeah. That that is that is the price. Like, my the the the reason that that the I'm I'm gonna call it the OpenPgpjs interpretation, and I'm sorry that I don't mean to pick on you, but I'm just using it as a as as a shorthand. The reason that the OpenPgpjs interpretation has been implemented is because it is potentially useful for the things that you described. I think the problem comes because then you you you're you're then committing to maintaining all of the historical self signatures over something back until the beginning of time, potentially just so that you know what the time evolution of this of the properties of this thing are. And I suppose my argument is that, yes, that is sophisticated and potentially useful, but the cost of doing that is a is a huge amount of extra complexity and a lot of things to be to to be carried on. And, like, I can understand I can understand why people wanted this interpretation because it did it does provide much more flexibility. But in some ways, flexibility is, you know, adds a lot of cost. So
[01:00:45] Steven: Great. So I I think we're out of time. And, Andrew, if you're gonna pop your last slide.
[01:00:48] Andrew: Yeah. The last slide basically is that I'm proposing that we go back or we we we apply a simpler interpretation of of this validity where you only need to keep the most recent self signature over an object, basically.
[01:01:07] Steven: Okay. So this this sounds like something that would need some discussion, I guess, at some point. Yeah. Again, apologies for screwing up and only having an hour. We'll organize a a we'll send out a poll to to organize an interim meeting September ish, I guess. Seems like any anybody have think September ish is a crazy idea? No. Good. Okay. We'll do that. And thank you for coming along. We'll do the work group as calls as promised. Thanks to Scott again for keeping notes, and we'll see you at some kind of interim meeting in the near future. Thanks.