Session Date/Time: 24 Sep 2026 14:00
[00:00:37] Daniel Gillmor: Okay, folks. It is the clock time for starting the interim meeting, but I think we're going to wait a little bit. Probably give folks another few minutes to trickle in, and, we'll see how it goes. So just hang tight, and we'll start shortly.
[00:01:19] Andrew Gallagher: Hello. Hello.
[00:01:22] Daniel Gillmor: That worked, Andrew.
[00:01:25] Heiko Schaefer: Test test.
[00:01:27] Daniel Gillmor: You're very quiet, Heiko.
[00:01:36] Stephen Farrell: Also, a test test. And also, Stephen, yeah, you were muted. I was muted in talking. Yeah. Sorry. And we were looking for a somebody to volunteer for taking some notes if anyone wants to do this. Be most appreciated.
[00:01:50] Daniel Huigens: I I can take notes when I'm
[00:01:51] Stephen Farrell: not talking or presented. That's that's Great. Yeah. As as usual, we only need the kind of actions and stuff. We don't need a blow by blow. Any other volunteer note takers for when Daniel is talking?
[00:02:10] Andrew Gallagher: I can take notes when Daniel is talking.
[00:02:13] Stephen Farrell: Thank you, Andrew.
[00:02:16] Heiko Schaefer: Testing some more.
[00:02:20] Daniel Gillmor: Still pretty quiet, Heiko.
[00:02:24] Heiko Schaefer: Oh, crap. Computers.
[00:02:26] Daniel Gillmor: No. That's good. That's good. Yep. I
[00:02:29] Heiko Schaefer: did not change anything? Alright. I'll take
[00:02:31] Daniel Gillmor: that. Position of the microphone. So I think we should probably get started. There are several different things on the agenda, and Stephen is gonna need to go in forty five minutes or forty three minutes at this point.
[00:02:51] Stephen Farrell: Yeah. Apologies, everybody, but I I have a class to take at that time. So I'm sure you're
[00:02:56] Daniel Gillmor: doing very. Yep. We we can continue past Stephen's departure. Stephen, you've got the slides, the chair slides up right now. So just a reminder to folks, this is considered part of the IETF meetings, so the Note Well still applies. If you haven't read the stuff about the intellectual property rights, about being decent to each other, You should probably know those things, because those are supposed to be preconditions for participating. Because it's a remote interim, we wanna ensure that folks are, able to hear what's going on. If you've got a headset, it'd be great if you could use it. And if you can try to keep yourself muted with video off unless you're chairing or presenting, or speaking from the queue, that would be great. So we have a bunch of different things to cover on the agenda. So Stephen and I, you know, wanted to we'll do a bit of a news trivia, briefly run through the status of the working group drafts. I'm not gonna go into too much detail on these because I think most of the ones that are adopted and underway are gonna have presentations by the lead editors. And then on the agenda, on the right hand side, if we can get through these, we'll see them. We've got the first four items are adopted drafts, and then the last three are things that the working group might be interested in. We'll see how far down into that we can get to the extent that folks have capacity for it. Yeah. Anybody need to adjust something here? Something missing? Barring that, we should probably go ahead and continue. So, I believe the Stephen's bringing up the next slide deck. But, Daniel, I think you're first. So I guess, Andrew, that puts you on the notetaker front. This is about persistent symmetric keys. Alright.
[00:05:16] Daniel Huigens: Right. Should I okay. Yeah. Great. Yeah. Thank you. So I will give a status update. First, I recently pushed a new version of the draft, that had been a while, so the previous one had expired. So there's not very many changes, but one substantive one is that we now explicitly disallow, using symmetric algorithms weaker than a s 128, which is, like I mean, people, I think, wouldn't have done anyway, but probably makes sense to say so explicitly so that, we can also reject them, in the code and so on. Other than that, there's a bunch of editorial improvements, thanks to, both Heiko and DKG, and others. And, yeah, that's that's mostly it. Then we now finally have a fully green interrupt test suite page. Last time I showed you this page, our SOP didn't yet have support for, using locked persistence metric keys for encryption and verification. But now thanks to Heiko, it does. So, you know, we have full, full interrupt tests. These are using the latest version of the persistent symmetric keys draft. They are not yet using the latest version of the proposal for which I will get to. But so, yeah, we can use this to demonstrate interrupt for the persistent symmetric key drafts, but not, like, the the sub considerations that I'll get to. Then, though, in parallel, some some new open questions and some old open questions came came up and came back up on on the mailing list and also, you know, in the issue tracker and on the Delta chat group. One is should we allow making, let's say, local certifications over third party certificates? Yeah. There's a there is a Delta chat group talking about some over topics kind of informally. I don't I don't wanna say it's like IETF status, but in any case yeah. So one is, talking about should we, allow making certifications, over third party certificates using persistent symmetric key. So if you have a local let's say you want to have a trust route key, it would make sense to be able to say, okay. I trust, this certificate, to belong to this other person. But, currently, we don't have self signature, so there's no way to say whether, well, whether the key should be appropriate to be used for that as you would with an asymmetric key currently. So there's kind of two options. One is we add a self signature again. We we used to have the possibility for that, but then it was removed in dash o two, I believe, following working group feedback to kind of simplify the the package structure and the format of persistent symmetric keys. But we could, of course, add it back if we think that's useful, or the other option is to just say that we always allow persistent symmetric keys to be used for local certifications since or you could store it in some metadata yourself if you want, like, what you want to use each key for. Since there is no, real need to communicate this information to others, then maybe that's fine as well. But perhaps you want to store it for yourself in a standardized way. So that's one, and the other is about, revocations. It's kind of a similar question, which is, like, what if you accidentally, like, leak the key or whatever? It gets compromised and you don't want to use it anymore, but you still want to keep it around to decrypt old data maybe. Then maybe you want to mark it as, like, don't use this key anymore, and then having a replication signature could make sense. Then again, same argument, you could also say, well, just store it store that information for yourself in some other way, and, you know, no need to communicate it to someone else. So, yeah, those are the main open questions that I know of. One possible compromise I wanted to voice is we could kind of fund this question in the sense of, okay. Like, for now, maybe there's no, nobody if there's nobody speaking up that they say that they want to do this or that they want to create self signatures or, replication signatures, we could say it's not something we want to do for now, but we keep open the possibility of adding them in the future and kind of make the persistence metric key grammar a bit more lenient to possibly allow them in the future. Then again, we could also say that I mean, for now, we just keep it strict. And if we want to add them later, we can always update the grammar at that point. But yeah. So those are kind of the the the raise range of options, I think. And, yeah, I will actually pause here for discussions because the rest of the presentation is kind of about SOP and and other stuff. So if someone wants to, yeah, voice an an opinion, please do. Mhmm.
[00:12:07] Daniel Gillmor: Speaking from the floor here, not as the chair. It occurs to me that we have a novel packet structure a novel a novel packet. And we could also just put a flag in the packet that says Yeah. Expired or certification capable or something like that and not have to worry about the entire packet grammar. So if we think that there's, like, three things that we want to say, we could just have a standard place for saying them in, you know, in in the packet itself and not open the door to all of the, like, baroque complexity of the of the packet grammar, the sequence of packets grammar. I I'm I'm only raising this just because I read, I recently read Peter Goodman's email to OSS Security, complaining about the packet grammar in OpenPGP, which I will probably raise separately on the list. But if we wanted to avoid that mess and still provide it sounds like we have maybe four things that we specifically care about. Like, don't use this anymore, accept it for certifications, accept it for data signatures, and accept it for encryption, decryption. Or maybe, actually, we only have the three, and you could just flip all those things off if you want people to not use it anymore. Right? You could Yeah. We we could just drop those in and say, you know, this this is where you put that information in this packet, and that's that.
[00:13:43] Daniel Huigens: Yeah. That's definitely another option. I yeah. Andrew?
[00:13:48] Andrew Gallagher: Yeah. Just to pick up on on suggestion. It sounds like what we're talking about is putting in an unhashed sub packets area into the into the new symmetric key packet. Because then you can drop in nice things like expiry dates and key flags and and so on without having to have a full signature structure. I'm not sure how you would how you would denote revoked using sub packets, but I'm sure there's a way to arm wave around that.
[00:14:20] Heiko Schaefer: You know? You could use
[00:14:22] Andrew Gallagher: you could have notations as well. It's, you know, it's beautifully extensible.
[00:14:28] Daniel Huigens: I guess you could say it's expired as of now. Right? But, yeah, it it does kinda feel like we are kind of then reusing the the the stuff that we already have, but in a in a different place. I I I would have to think about whether it then makes sense to actually authenticate them using the key, though. I'm I'm not sure if there are cases or scenarios where may maybe it's better to then authenticate it. Right? And and maybe at that point, it makes more sense to just have a symmetric signature since that's what essentially it would be. Right? But, yeah, that's something we could think about. I I personally like the fact that the persistent symmetric key packet as it is today is just the exact same as a secret key packet. Right? There is, of course, the the algorithm specific, key data still, but other than that, there is no difference. If if we're, you know, introducing additional fields, then we're kind of making the proposal more complicated. But yeah. I mean, it's definitely possible.
[00:16:01] Andrew Gallagher: Yeah. Just just I I
[00:16:04] Stephen Farrell: guess, general question, what what's the path forward do you think in terms of getting done more revisions, blah blah blah? What what's your take?
[00:16:13] Daniel Huigens: Yeah. I mean, I if if we agree that we want to change something here, then, I mean, we will definitely need another revision. I so maybe I should ask first the the does everybody agree that it's reasonable to put this information somewhere? Because there's also, like, the option of, like, we don't do anything. Right? Because, I mean, for us, we don't we don't really need this information. I will just say, like, from from the side of Proton, I mean, I it's not that I'm opposed to putting that information there, but, I mean, we probably won't really use it. So if there's someone else who wants to speak up and say that they would want to use it, that would be great, but I don't know if we have that. Heiko?
[00:16:59] Heiko Schaefer: So I have the opposite point of view just to put it on the record here. I would like to keep this as simple as possible, and if we can, in any reasonable way, like, just not put any of that metadata in, that would be my strong preference.
[00:17:13] Daniel Gillmor: So yeah. Yeah.
[00:17:19] Daniel Huigens: I mean so, yeah, part of part of my thought of proposing punting the question was, that, like, you know, if if we don't have any people speaking up that they want this stuff I mean, that they actually want to use this stuff, then, like, maybe we shouldn't do this now, but at least keep the possibility open for I mean, to do it in the future. But then, obviously, like I mean, we can't change the packets in the future. Right? So if we want to put it in packet, then we should do it now. But if we want to do it in a separate packet, then we could do it later. Andrew?
[00:18:00] Andrew Gallagher: At the at the risk of sounding like I'm flogging my pet hobby horse, you can put anything that you want that is implementation specific inside a trust packet and stick the trust packet into the packet sequence. And, you know, nobody else needs to know nor care what it means. If you want to specify a standardized way of doing it, you can. Otherwise, you know, you can just make make up your own private one and that's good as well. So, like, there are I'm just saying there are ways of doing this in a way that don't require us to actually hard specify a wire format for every single thing that we want to say in, you know, a a packet sequence as options exist.
[00:18:46] Daniel Huigens: Yeah. I mean, the other struggle I kind of have is, like I mean, we already have packets for all this stuff. Right? Like, we have replication signatures, and we have, you know, ways to let the key expire. So I if if we want those things, then I I would kind of be tempted to say why not use the thing we already have. Right? But, yeah, Heiko.
[00:19:12] Heiko Schaefer: Right. To pedal back, like, 10%, like, we specify that we're happy to have a signature and for implementations to ignore it, I'd be okay with that if we say that there can be a direct key signature, but not, like, sub keys and, like, identity stuff. I'd also avoid but, like, saying, okay. There may be a signature and implementations may just ignore it. I I wouldn't fight that tooth and nail.
[00:19:36] Daniel Huigens: Yes.
[00:19:37] Heiko Schaefer: Reasonable to keep that door open even though I'd hope we never wanted.
[00:19:41] Daniel Huigens: Mhmm. I think we, for sure, shouldn't add subkeys and user IDs. I I don't think there's any, like, reasonable use case for those. If if we want to allow adding replication signatures in the future, the only question we have to answer is whether we want the key to be rejected today or, like, in our current implementations if we add one in the future. Right? Like, the other thing we could say is, well, actually, we may want to add them in the future, but then if you add such a signature, then it should be rejected because, like, maybe it will be revoked at that point, right, or or expired. So maybe we should actually keep the grammar strict for now. And then, like, if we want to add it in the future, then we can add those things once implementation is supported. Right?
[00:20:40] Heiko Schaefer: Mhmm. I think one way to look at my discomfort with this whole extending the grammar is that we don't even know what the semantics for the existing stuff is, and then adding a new thing on top scares the hell out of me. So maybe we could also say once we've cleaned up all the like, what the hell does this grammar mean and, like, what are the semantics of PGP anyway, like, maybe then is a good time to add this.
[00:21:03] Daniel Huigens: Mhmm. Okay. I I I guess we will say that we need a bit more discussion, and then I will, you know, create another draft once we have something. And then, hopefully, we feel ready to to go to working group last call.
[00:21:28] Daniel Gillmor: Mhmm. Daniel, if you if you could formulate your one of the proposals that you think would be a reasonable one that you'd be willing to accept Mhmm. As a as a merge request and then post that to the mailing list, then we can just see whether anybody in the working group has a problem with that or if people prefer you know, can ask we can ask people something concrete. Like, do you want this, or would you rather stick with the status quo? And, that might help us just to to resolve this.
[00:21:58] Daniel Huigens: Yep. Sounds good. Will do.
[00:22:00] Daniel Gillmor: Great. Thank you.
[00:22:01] Daniel Huigens: Thank you. Then I will move on to sub considerations. So I talked about this a bit last time, and this this proposal in particular of allowing to use sub encrypt, but we tweaked it a bit partially from feedback from DKG is that now I mean, the latest merge merge request that I made was to add an option called with key to allow passing secret keys to the operations that have traditionally used public keys such as sup encrypt and verify. And then you can also pass with key passwords to unlock those keys. And part of that was merged for sub encrypt, although we haven't updated our implementations yet nor the test suite. But then also there was further discussion after that whether that's actually the right path to go. And in particular, there is a counter proposal also from DKG that involves adding with p PSK option instead. And then either also adding a with p PSK password option or adding or using a separate command, to decrypt the PSK first and then only allow using, an unlocked PSK, in sub encrypt and inline verify. So we have, yeah, a bunch of different options there. And while I was thinking about that, I realized at some point that there is a parallel consideration around the the KOpenPGP attacks, which were public we we published in 2022. And, the the core of the text maybe everybody here knows, but as a brief refresher, the the core of the text, is that if you have a private key, locked a private key stored, on some potentially untrustworthy, storage, and you have an attacker that can overwrite the public key material in the private key and you then subsequently use the, the locked private key, then there are compromises possible. And, like, the most relevant one here and maybe also the most obvious one is that if you use the public key material stored in a private key to encrypt some message or to verify a message, then, well, it's not authenticated. Right? So you don't know that it's your own key, so it might be, yeah, just a random public key. So, part of what was done in RFC 9580 to address this, is, that now the public key was added to the additional data, of AAD encrypted private keys. So if you first decrypt the private key, then if the, I mean, if the AAD encrypted data decrypts successfully, then you can know that the public key material is also authenticated by your password, and then you can use it safely. But you do still need to decrypt the keys before using them if these are, attacks are in your threat model. Otherwise, it hasn't solved anything. So, concretely, in SOP, this means that, if we want to address these attacks as well, then we might actually need, this same option that was in the first proposal for asymmetric keys as well because you might want to sop encrypt with a private key that is locked. And then, you know, the implementation should decrypt the key and check the public key material if it's not a d AAD encrypted. If it is AAD encrypted, then and that's done automatically. And then you can use the public key to encrypt. So I I made a merge request to propose that. Then there was counterproposal to that as well, which is to just only, add an option to extract cert. For example, verify password, which would decrypt the the key in that case only and then extract the the public key material, and then you could use it as normal as you would today in the in the sub API, which for for the record, I think it's a good idea anyway. But yeah. That would be opposed to, like, doing that everywhere. So here's table of the different options or two, yeah, the two main options I described. On the left is the first one, and on the right is the second one. So this is, yeah, how the API could could look completely. Obviously, you know, the option names are kind of up for debate in both cases. But in any case, it should give the rough idea of how it could work with the ones on the left being kind of more integrated if you want, doing everything in one command, and the ones on the right needing two commands to do these things. But then they are, let's say, in some sense, more orthogonal. And, it will come as no surprise to, to anyone that's, my my preference is for the options on the left for a few different reasons. One is I think it's more more ergonomic. Two is I think it's safer as well. I think with the option on the right, there is a risk that you might accidentally leave some unlocked key material lying around somewhere on disk or a public key public key material that has not been authenticated or might get overwritten at some point in the future. Obviously, if you're running these commands right next to each other, then there's virtually no risk of that. But, if you then leave the objects lying around and you reuse it again later, then you're kind of increasing that risk. And, you know, in the option on the left, especially for the first one, the implementation could just keep the the unlocked key material only in memory rather than, having to, yeah, have it on disk, somewhere. Then three is I think that, the options on the left are more consistent with each other since they're I mean, they're essentially the same. So, I mean, cannot really get more consistent than that. I also think they are more consistent with the sub API as it exists today, which doesn't require you to unlock persistent sprinted key material, before using it in any other case today. And even if we were designing the sub API today, I don't think it would necessarily make sense to to do that in my humble opinion. So and and finally, I also, kind of think that the the options on the left reflect more, like, what the user actually wants to do. I mean, they are more, like, high level operations that, yeah, reflect the intention of the user. Whereas, like, in in the option on the right, like, on the bottom right, for example, the user very actively or the application developer, let's say, has to very actively be thinking about, okay. I want to protect against this specific tag, so then I I'm gonna do this thing, which is, like, if the developer is very aware of these attacks, that is potentially possible. But, otherwise, I I think that's, again, risky. Then on the other side of things, I would say I'm not the the best person to, you know, defend the the second proposal, but you put the one of the things that has been mentioned in favor of it is, again, that it's, in some sense, more orthogonal. The other thing I've heard is that, for the, for the people that don't care about the KOpenPGP attacks, it's kind of nice to kind of compartmentalize this stuff, let's say, in a separate command, and then, like, you don't have to worry about it so much everywhere else, which is, I mean, makes sense. But at the same time, I think for the implementations that do care about it, at least in my view, it's it's not really sufficient to just provide a new command for for application developers to deal with and kind of say, okay. Well, we've addressed the K OpenPGP attacks, like and then, you know, here you go. You can use this command. I at least for me, for our implementations, I would want to, at the very least, well, I would want to address the attacks in the existing commands as well and, at the very least, issue some kind of warning in the cases where, where the attacks could have occurred in the API today. So, yeah, in that sense, I I personally think that that that proposal on the right is not not sufficient by itself at least. But, obviously, I'm biased there. Yeah. TKG.
[00:32:49] Daniel Gillmor: Hi. So I wanted to just speak towards the the different choices here because I think I've been one of the folks pushing more in the direction of proposal two. Although, I don't think I'm pushing only in the direction of proposal two. The cut line that I think is when you're operating on public key material, you shouldn't need a password. And when you're operating on secret key material, you should. And so we have sort of there there's two different things to think about here. And I The KOpenPGP attacks are described as attacks against your personal public key material. But if the attacker is allowed to replace, arbitrary data on in your storage, they could also replace your correspondence certificates. And there's no the the proposal one doesn't provide any defense against that at all. Right? There there's still a heavy burden on on the the application to make sure that the various certificates that are being used are have not been tampered with. And having a special case for dealing with your own key doesn't sound that important to me. And it what it does break here is there's this symmetry of when you're are you using search and when are you using keys in the in the API? So I'm leaning towards something that's in between these two proposals, which is allowing the use of passwords and, when you're passing a PSK, and not, but but otherwise, for things like if you're using the public key material, you really have to pass asserts for that. And so I would say what that does is it actually keeps the PSK work sort of isolated, in SOP. So there's this PSK functionality, and you can implement that or you cannot implement that. And then there's this everything else you're dealing with public keys versus private keys. It's actually keeps the asymmetric stuff asymmetric. So I can try to propose a a concrete merge request in SOP that will that will do that. Maybe we can bring the two options to the list and let people choose like, people look at at what the different things are. I really appreciate working on this with you, but I just wanted to make it clear. Like, I don't know that we need to go all the way to proposal two if we just wanna say, hey. Here's how PSKs stuff can work.
[00:35:22] Daniel Huigens: Yeah. Fair enough. I mean, so the last the proposal too is my interpretation of I mean, part of what you mentioned in the issue. But yeah. Yeah. Apologize if I didn't fully represent your proposals correctly. But I do want to respond to the first point, which is you shouldn't need a password to use public keys, which if you accept the the KOpenPGP attacks, is is just not true if you have, your public key material authenticated using your password. Like, if your security model is that I'm I'm entering my password, then I have authenticated my public key material using that, and then I can use it, then, obviously, you do need to enter your password. I I understand that's not, like, how how people are maybe necessarily thinking about key authentication today. And a lot of the time we may we mainly think about key authentication of other people's keys. Right? And you're also saying, well, this doesn't address that, which is true. But we do have an existing command in soft that that does address that, which is validate user ID, which obviously I mean, there are many different ways to do key authentication. But one way you could do is is, you know, you make some certifications of the public key material of your peers using your own key, for example. And then later, you can verify those certifications again, and then you presumably know that, like, it's still the right public key, and you can use it safely. Right? And that works, but it only works if you can authenticate your own, key as well. So there is some inherent asymmetry there in, like, how key authentication works, which is that you can only authenticate other people's keys once you've authenticated your own key. Right? And how do you authenticate your own key? Well, OpenPGP doesn't necessarily have a very good answer for that that everybody agrees on. You could just say, okay. Well, you store it on some secure storage, and that's fine. Or you store it in hardware, that's fine. Although, then you still need to check that the public key corresponds to the private key that you have stored in hardware, right, which is kind of what this is trying to do. If your answer is, okay. I store the the key material encrypted on disk, then I I I decrypt it with my password, and then I know it's the right key, then I mean, that's the model that KOpenPGP operates in. And then you you kind of do need something like this. Heiko.
[00:38:37] Heiko Schaefer: So I one thing I like about SOP is that it's really small and quite opinionated and, like, that things are, like, easy to discover and understand what they are for. So I tend to like DKG's idea of keeping PSKs in their own subset of the CLI API. So this is, like, one point I wanted to make. And another point is, as I was looking at your slide to the proposals, I totally agree as a CLI tool, one looks much better than two. But if I wonder, like, in the future, are we envisioning SOP as an application building block, as an API in applications? And then I would say, like, something like proposal two starts looking much better to me because it's composable with the individual things have a meaning that makes sense to me, and I can unlock something as an application into my memory, use it from there, and then safely, whatever, zero eyes, this card, like, definitely not persist on disk. So maybe, like, these specialized use cases where we defend with PSKs against k open p g p, maybe those don't need to be the most elegant thing in the CLI use of SOP. Maybe we need to think about consuming SOP as an API in these cases. And if that's possible, what maybe these concerns can be somehow traded off sensibly against each other.
[00:39:52] Daniel Huigens: Andrew?
[00:39:56] Andrew Gallagher: Yeah. I I just I'm just I'm just worried about the the top right one, which seems to encourage people to unlock their secret key material and write out an unprotected secret key onto disk storage. I I I just think it's a really bad paradigm and bad habit to encourage people to use. Now like Heiko says, it makes a lot of sense to be able to unlock something then hold it in memory for an API use case, but for a CLI use case, there's there's no holding in memory. You you write you have to write it to persistent storage between your your your steps. And, yeah, I think I I tend to agree with Heiko that maybe this is somewhere where this where CLI usage and API usage do actually differ in important but subtle ways. So, yeah, we need we need to be very careful of anything that encourages or lets people accidentally write out secrets to disk because, you know, even if it's a local private disk, you know, you've got, you know, you've got SSD, where leveling and whatever, you know, anything that's written to a disk. You know, it's it's it's already kinda leaked somehow. You've you've you've transgressed some kind of boundary by doing so even if you do clean up after yourself religiously. It feels feels hairy to me.
[00:41:27] Daniel Huigens: Yeah. I I wanted to say one last thing about isolating PSK, which is I I personally disagree that applications should have to think about specific algorithms or whether a key is symmetric or asymmetric. So, I mean, to me, anything that has, like, PSK in in, like, the name in the top level API seems like mistake to me, but I I agree that I mean, I can understand that for people that don't care about persistence metacase, maybe they want to, like, put this in a quarter or something. But I I just like, for for an end user and even for an application developer, I I think that's not, like, the I I don't think we should ask them to to think about that, but that's just my opinion. I will stop there.
[00:42:25] Daniel Gillmor: Okay. So we are almost halfway through our allotted time, and this is the first presentation of of six. So no. No. It's not your bad. This is a complicated thing, and I'm glad we got to air the the, you know, the range of options that are here. But you have two more slides in this deck? Do you
[00:42:40] Daniel Huigens: wanna just to say, like, I will well, I was gonna say I'll make a new version, but I will first post to the list and then possibly make a new version, and then hopefully, can go to, working with last call. And that that's all for me.
[00:42:53] Daniel Gillmor: Okay. And I just wanted to clarify that the reason we're we're we're trying to hash this out about the SOP business even though SOP is not an adopted working group draft is that SOP is the way that we can formally test Interop. The current interop test that's been done is is using non standardized SOP commands, and so we need to figure out how to, just how to how to address that. We wanna make sure that it's written down in a clear way that multiple SOPs can implement it and do it in a in an aligned way.
[00:43:23] Daniel Huigens: Yeah. I mean, personally, I also think that we should bring SOP to the working group and, like, also think about it not just for the purpose of interrupt testing, but also, like, how do we want people to use this stuff in a high level API. Right?
[00:43:38] Daniel Gillmor: Yep. That makes sense. And nobody has raised that clearly enough. Like, we we don't have a slide deck or anything to discuss that, but that does seem like something that we should probably talk about maybe at the next ITF meeting. And I I you know, as one of the lead authors on top, I'm happy to take it to the working group if people think that's the right thing to do. Let's just get our other stuff cleared off the decks. So thank you, Daniel. Queue is locked, so let's move on to the next presentation.
[00:44:06] Daniel Huigens: Thank you.
[00:44:08] Daniel Gillmor: I think that's Heiko on external secrets. Let's see here. I think you can request the slides from me somehow, maybe in the three dots.
[00:44:29] Stephen Farrell: You can pass the I'm
[00:44:32] Heiko Schaefer: not sure.
[00:44:35] Stephen Farrell: I just passed control.
[00:44:36] Daniel Gillmor: Great. Thank you.
[00:44:38] Heiko Schaefer: Oh, I see the control. Awesome. Okay. This is one of two slide decks. I'm going to briefly explain why there are two and what the difference is, and then we go into this one. So there are two slide decks here and two drafts that somehow concern themselves with hardware based secret keys, for example, an open PGP card. And this one is about how to represent those as stored objects on disk, and this is the externally stored secret key format. We've talked about that in IETF 126. This is a brief recap and update. So I'll go to the recap part. So the goal is to have hardware backed secret keys and to have interoperable representation of those. So, for example, open PGP card devices like UBTEs or TPM or any hardware security thing. And they should be stored as standardized transferable secret key stubs. So they look like TSK, but they don't contain the secret parameters, not even in locked form. We have an approach in the draft that is suggesting a new S2K usage code point that signals the secret key packet is only available externally, and we're still working on a hint representation what exactly we want to represent as metadata about this external secret key data. So now the status, the editorship changed. D k g started this draft and stepped back as an editor, and Paul Sharp joined, which is great. So now it's me and Paul writing this thing. We had adoption very recently, which is exciting. They're experimental implementations, multiple ones with different strengths and different focus. But that's all kind of already been the case in 126 as well. So the next steps were, as I said, currently discussing different aspects of the locator hint that is stored besides the high level fact that key material is external. There is a change that is suggested to make the default behavior mean not best effort as it was before where an application is asked to just search for the key material in any way it sees fit and to say that no low heat variant actually means the key material is unavailable, which is a rare case, but we thought maybe it's nicer to have this as a default. There's discussion under the link in the GitLab repo for the draft. And the the second one, best effort explicitly is the counterpoint to the unavailable default. So the two meanings are encoded in specific ways. There are merge requests for that. And then the third point, optional device name, that is a suggestion that I think I made. I think it's good to have a user facing thing where an application can tell a user, hey. I would like you to plug in your hardware device with a green sticker and somehow inform the user which device contains the key material that they're trying to use. There is also issue for that. And then there is a merge request that origin originated with Andrew about doing some registry cleanup to decouple the S2K usage and symmetric key algorithm registries, which are currently coupled for historic reasons. So there's a PR where we're discussing that, And that's all the updates or status report for this that I have.
[00:48:33] Daniel Gillmor: Thank you for that, Heiko. I don't know if anybody else has, read or considering implementations, but it'd be like, this is, very recently adopted, and so I hope people will take a look. And even if your implementation doesn't support hardware backed keys, it might wanna be able to provide clear error messages and, you know, some updated pointers to that. Also, if you're interested in the existing registries and about the registry, decoupling efforts that are going on here that Heiko pointed to a link there. So if anybody has any comments, now is a good time to get in the queue. Otherwise, we can move over to the next, talk. Thank you for the report, Heiko. Seeing nobody in the queue, I'm going to, switch over to the next, slide. Thank you, Heiko. Andrew, I think this is you here. Let me get the slides shared, and then you can request them from me. Somehow, I can give them to you. I'm just gonna hit next because I can't seem to give you you just tell me next, and I'll do it. I can't seem to give you the controls.
[00:50:10] Andrew Gallagher: Okay. Okay. Sorry. Fair enough. Okay. This is HKP. We've talked about this a lot, so I won't bore you with the the the the gory details on it. So next slide, please. So the current status of this and of basically, I have a couple of other slide decks which we might get to. The current status of all of these slide decks is I'm being busy. I've been busy specifically over the summer with implementing HKP RFC ninety five eighty and ninety nine eighty in Hockeypuck, which is now done mostly, but I'll get back to that on a on a later slide. The the upshot of it is I haven't had time to do much editorial work on any of the drafts themselves. And I've been away for the last two weeks so I'm literally just back a couple of days ago and I'm a little a little disorganized and frazzled at this point. What I'm hoping to do is get all of these tied up in time for IETF 127. But in the meantime, I just wanted to ask the group a few questions, maybe just to focus minds on a few of the big questions that
[00:51:35] Daniel Gillmor: are
[00:51:35] Andrew Gallagher: required before we go and get to IETf one two seven, by which time I hope to have a new draft of all of these ready. So this slide is basically the same as I gave at IETf one six. So there's a lot of outstanding work to be done in terms of specifying the JSON formats in some sort of formal schema. And I had initially suggested using JSON LD. The reason for that was that we're trying to specify email based authentication which naturally led to the idea that we should align with the structured mail working group and the structured mail working group have standardized on JSON LD as their BS, as their BS protocol. Unfortunately, it it has kinda come to light after the fact that JSON LD is quite a heavy spec, and, it has been suggested that maybe using JSON Schema rather than JSON LD is a better idea. So not being very okay with either JSON LD or JSON Schema, I got quite bogged down in this high level decision. So I will defer to the JSON experts, whoever they are in the room, as to which way we think that this should go. I think it is it isn't necessarily a blocker that we need to align with structured mail because most of the JSON that we're going to specify in HKP is actually, in HTTP responses. The email section of JSON is actually quite small with the that's used for authentication tokens over email and those can be anything. They don't even have to be JSON, but using JSON makes makes sense because it's, you know, any in the old client should be able to parse it with a standard library. So I will leave that sitting there. Can I have the next slide, please? I'm quite conscious of time. So the current status of the HKP is, like I say, Hockey book 2.4 is out. It was released about three weeks ago, I think it was. And, most of the public, SKS network, Hockeypuck servers have been upgraded to 2.4 and do support h k p v two. And full post quantum 9580 and 9980 including SLH-DSA, but I'll get back to that in a different slide deck. The the one major exception to that is Ubuntu who are a little bit behind. I've I'm I'm talking to Ubuntu about I think there's a new team taking over the key server, but that that that kind of communication channel is a little slow. So, hopefully, Ubuntu will be will be upgraded. So there's nothing yet in hagrid. I know that Heiko has has volunteered to work on, and I've said this quite a lot. And, unfortunately Heiko has a lot of other things on his plate at the moment, so he will probably get around to it, but it is it is currently still pending. There is no explicit client side support for anything. However, I am hoping that we can knock together a basic command line implementation. Heiko has expressed interest in doing this and I also want to do it myself. So we should have, shortly, two simple command line interfaces. They'll basically be a wrapper to lib curl. But now that the public key servers are serving HKPV two, It should be very easy for for existing clients to start experimenting with h k p v two hookups and getting, v six and p q c keys out of the SKS servers, which already have some p six and p q c keys on them. So, hopefully, that's, that's going to pick up. The one thing that hasn't been implemented yet in Hockeypuck is canonical bundles because that requires a little bit of extra work. That will be my next priority on the implementation side. Next slide please. So, the open questions, the first one is do we need to define a dot well known path? This is this is for alignment with standard HTTP protocol practice. The because because, h k p defines fixed paths, it's generally considered a bad form to define fixed paths, and thereby blocking off, an arbitrary piece of, namespace on every bloody server that, you want to deploy the HKP. The the proper way to do this now is to have a well known path, and then the well known path will either serve stuff over that or point you to the, the canonical location. And there may be a default place for that, but it should be possible for people for implement sorry, for operators and people who deploy the software to change that by changing the dot well known. That, unfortunately, adds an extra round trip, to the requests because, previously in h k p v one, you just assume that everything was on their PKS lookup and use the PKS lookup and stuff will be there or it wasn't. WKD is specified to use a path under dot well known, but it is also considered bad formed but large amounts of user addressable or user modifiable content under dot well known because it tends to be served from system locations. So this is an open question still. I am not even sure myself which one I prefer. I I I'd actually just actually, to be honest, I'd just prefer to be able to use PKS as we have done, but it's no, you know, it's no longer considered best practice. And so if we want to get this signed off and published for the IETf, we will probably need to use, well known in some fashion or other. So, I will throw that open to the, to the group. Daniel?
[00:58:31] Daniel Huigens: So I'm I'm not, like, a 100 familiar with with the recommendations of the HP working group, but I would kind of assume that, like, the recommendation to only specify a dot well known path would apply most when you're recommending something to implement something to be implemented on a general web server. Right? Mhmm. Like, if we were specifying something that any website or any email domain, for example, should implement, then I think that's a very reasonable recommendation that we just shouldn't just define an arbitrary path. Right? If we are saying, no. This is a specification for an API that will run on servers that are dedicated to running this API and also on domains that are or at least subdomains that are dedicated to that, then I I wouldn't think that that consideration applies, but I might be wrong. Obviously, there are some still some color consideration of the the overlap with the, let's say, WKD like functionality, which is generic to all email domains. Right? Like, if on all email domains, we want to be able to say, well, please look up the keys from this HKP server or from this location in general, then I think it makes perfect sense to either define a dot well known path, or a serve record. But I don't think it makes any sense to say, okay. We define a that well known path to point to an h HKB server, and then on the HKB server, you again look up that well known path to go to some other location. I think that's overly redundant.
[01:00:33] Andrew Gallagher: That would be my feeling as well, instinctively, but my my worry is that the the HTTP people may have stricter views of such things. Look, we could we could we could potentially engage directly with them and ask them for an early review or even informally just say, you know, pick pick somebody who who who knows better about these things for for advice. DKG?
[01:01:06] Daniel Gillmor: Yeah. Let me just explain what I think is an issue here. There are two pieces to this HKP draft. One of them is how do you publish an a tree an a URL tree that meets the HKP specification. The other one is given an email address, how do I find a particular HKP implementation to go to it? And, I think the modern expectation is for the former, you assume a URL prefix. You don't get to the spec doesn't decide what that URL prefix is in full. It doesn't decide the domain name, and it doesn't decide the the root. But somewhere, there's an HKP tree. Right? And so within that HKP tree, there's you know, we can define what the rest of that stuff looks like. And then for the second part of the problem part of the puzzle, it's the dot well known how does the dot well known point to that tree for a given domain? And I think if we can make that clean distinction I'm I'm willing to take a crack at at proposing such a cleanup in a way that I don't think will be particularly offensive for what you're trying to do. The only difference here is that if we don't pick a default path, then the SRV record is not gonna there needs to be a default path if we go the SRV record route. Right? So if example.com says, do my HKP lookup over on this server via SRV record, then it the SRV record doesn't contain a path. So we have to declare what the what the root pre the what the path prefix is for the for the SRV scenario if we define the SRV records. And I think those are the two things, and I think we can do them distinctly, and I think it's gonna be fine with that. If you wanna do a generic HKPS lookup v two lookup using your preferred key server, then you need to know your preferred key server's domain name and default prefix path. So you'd know that you're doing your lookup under keys.openpgp.org/hkp or /pks/vtwo, for example. Anyway, I'm I'm I'm willing to take a look through this and try to write that down in a way that I think would be likely to pass the review. And, yeah, we can put who's taking notes right now? Daniel,
[01:03:38] Andrew Gallagher: I think.
[01:03:39] Daniel Gillmor: Daniel. Yeah. If you could put in the notes that I'm volunteering to do that, that'd be great. But I realized the time has also run out, and I don't see anybody else in the queue. So I'm inclined to try to move us to a next presentation unless, Andrew, you've got more questions for the group. Oh, we got one more slide here.
[01:03:53] Andrew Gallagher: The the the the one more slide is just the is just the links. The the other questions that are on that page there, I've already mentioned the the issue about JSON LD versus JSON schema. But the the the one that I haven't spoken about is using serve records for non discovery use. And this is actually something that came that that was introduced way back in the in the SKS key server pool days. And actually, some of the existing key servers, as in some of some of the key servers that have survived from the SKS key server, they still use them and GnuPG still supports it. And we have actually run into some issues recently where there have been glitches in the SRV record configurations on some key servers, and that has actually broken GNU pg. So I think it's something that we at least need to address even if it's just putting a big flashing warning, but I actually think having the SRV records is a good idea. It was in Daf's original draft as a suggestion. What actually got implemented was totally different from Daf's original suggestion. So this was removed from an early version of the IETf, HKP draft. I think we we should seriously consider putting it back in, but putting it back in in in the way that matches the existing, deployed usage rather than the aspirational one that that, that Daf originally suggested way, way back. So that's me.
[01:05:38] Daniel Gillmor: So, Andrew, will you or Daphne write a merge request for that to raise and bring to the group?
[01:05:43] Andrew Gallagher: Yeah. I will. Yes.
[01:05:45] Daniel Gillmor: Great. Thanks.
[01:05:47] Andrew Gallagher: That's and that's that's that's it. Thanks.
[01:05:54] Daniel Gillmor: Alright. So we have about twenty minutes left and I think three more slide decks. So I'm gonna try to go through these before have a chance to do it. It is we have the next next up. We have oh, sorry. Andrew, this is still you.
[01:06:10] Andrew Gallagher: Yeah. It's okay. This one's gonna be a lot shorter. Don't worry. So next slide, please. So key replacement, I won't go through the the the full thing that's been discussed to death on the list and elsewhere. The current status is essentially the same as in as at the IETf-one two six. The it's pretty mature. We have low level library implementations that do interrupt. So thanks to myself and Heiko, but no high level application support yet. Next slide please. So one thing that did come up recently and which I discussed briefly on the tracker, with Heiko was that there was a question previously about whether we should declare some members of the identity equivalent set to be non usable for encryption. So the idea would be that if you had multiple, as in multiple fallback keys or multiple deprecated keys in your identity equivalent set. You might you might want them to be equivalent for the purposes of people upgrading to your preferred key, but you may not want people who do not maybe understand your latest, you know, PQC preferred key to fall back to the older deprecated keys because maybe you've destroyed since destroyed the secret key material or you don't have access to the device anymore. So how do you do that? An old proposal that we discussed with Johannes way back was that, we should add essentially feature flags to each of the target records. So in the in the preferred key, in the reverse in the reverse replacement key sub packet, each of the target records mentioned would have a flag on it saying, encrypt to this or do not encrypt to this. And we threw that idea out because it was too heavy. It complicated the parser. It was completely overkill. But it occurred to me recently that there's actually a much, much simpler way to do this because as dkg mentioned in a in a recent email, the identity equivalent set is a fully ordered set. So when you were doing a search for the encryption subkey that you want to use, when you're encrypting encrypting a message, you you start at the top and you work your way down the list. And it would be relatively simple and relatively lightweight to just draw a line halfway down this list or partway down this list to say when searching for an encryption subkey, do not pass this line. Everything above the line is usable for encryption. Everything below the line is do not use for encryption. And the way that you would mark that is you put in some kind of stub or zeroed or otherwise, you know, special entry in your target list. And when you're calculating the identity equivalent set, that would be ignored. But when you're actually trying to find a particular subkey to use, that's that's the stop line and you do not pass it. Daniel?
[01:09:38] Daniel Huigens: I I kind of feel like the the only scenario where this makes sense to me is if you have some key that, like, you you want exist you you don't want people to use if they can discover and use the replacement key. But if they can't, then you do want to continue to use that them to continue to use it. Right? Because if you if you don't want to if you don't want anyone to continue to use the key, then you can just revoke it or expire it.
[01:10:18] Andrew Gallagher: If you have access to secret key material, yes. But if you have since destroyed or lost the secret key material, it would be nice to to have a way on the preferred key to say, by the way, these keys these are my old keys, so they are legit. But I but I don't want you to use them because I won't be able to read a message if you encrypt to them.
[01:10:42] Daniel Huigens: So this only works if you, in the past, have declared the keys as equivalent
[01:10:48] Andrew Gallagher: Yes.
[01:10:49] Daniel Huigens: And then later want people to stop using the old one.
[01:10:53] Andrew Gallagher: Yep.
[01:10:54] Daniel Huigens: Yeah. Okay. I I kind of still would argue that in that scenario, maybe you should create a revocation certificate or something at the moment when you're creating all of this. And then just keep the certificate revocation certificate around. And, like, if then later you decide that you want people to stop using the key, then you can add that. Right? Obviously, that requires some foresight. But, like, this way, if, if we add it here, then whether you can use the old key or not depends on whether you interpret the replacement key, metadata, right, which I think is kind of not ideal. Like, I I would prefer to just say, like, the replacement key mechanism is for saying, okay. These keys are equivalent. But then whether you can use any of the individual component keys or not component keys, but, like, constituent keys, like, should still be determinable from the key by itself. Right? I would I I I would kind of prefer that. But I
[01:12:10] Andrew Gallagher: know this this does kind of bleed over into the idea into the into the more general idea of encryption subkey selection. And, you know, there there there there are other questions about, you know, do you encrypt to the best available subkey or do you encrypt to all usable subkeys and so on. And that that that is a completely separate question again. I think this is for a relatively simple scenario where you want to have essentially a trapdoor mechanism or a ratchet mechanism. So, yes, everybody that has your old keys can upgrade to your new keys automatically. But once they upgrade to your new keys, they're not going to fall fall back to the old ones again, which then draws a line and then you can destroy your old key material. Or if you lose the old key material, it doesn't matter. Dkg?
[01:13:08] Daniel Gillmor: Yeah. Just without any chair hats on, I have to say I would prefer to not encode this year Okay. For similar reasons to Daniel. There are other ways to do it. If you're gonna destroy your secret key material deliberately, you could create your revocation certificate before you destroy it. That's not an unreasonable thing to do. And I also just wanted to point out that from a usability perspective, not clear what to do. If I've got an equivalent set and I'm trying to send you an encrypted message and I've reached the stop line, what you're telling me is I can't send you an encrypted message.
[01:13:43] Daniel Huigens: If
[01:13:43] Daniel Gillmor: And so, you know, if if you really want me to not be able to send you an encrypted message, you need to revoke that key because I could not know about the equivalent set myself. Right? So I would prefer to keep this simple and keep this mechanism out of it. That's just my preference.
[01:14:00] Heiko Schaefer: Okay. Heiko? I agree that it would be nice if we could avoid having this mechanism. It's it's kind of irritating, but then, like, people losing access to their secret key material is a problem that people have, and it seems sensible to have some additional mechanism here to address that because it is a real world problem, which in an ideal world, we wouldn't have. It would be nice not to have the problem, but I yeah. It's a trade off. I I kind of like having this do not encrypt to thing just because people do seem to struggle with that.
[01:14:37] Andrew Gallagher: Yep. Daniel?
[01:14:41] Daniel Huigens: Sorry. Wrong button. Yeah. Sorry for not looking at the proposal very much in detail. But just to clarify, this this will be stored in the replacement key, right, in a new In
[01:14:52] Andrew Gallagher: the preferred key. Yes.
[01:14:53] Daniel Huigens: Yeah. So I I would kind of argue that this this specific information should be stored in the in the old key in some way. Like, if we want a new mechanism for this specific scenario, then I would say, okay. Let's create a new signature sub a new signature that is, like, critical and signed by the new key that says, okay. Here is a statement by the new key that the old key cannot be used anymore. And then if you don't understand the signature, then it's critical in some way, and you will reject the key. Or if you do understand it, then you can also see that, like, you can't use the key anymore. Right? I I would prefer that from I would prefer that over, like, having to look at some other key to decide whether I can use this key. Right?
[01:15:51] Andrew Gallagher: Well, I think I think if you're getting into the fallback key scenario, you have already looked at the preferred key because you've already decided that the preferred key is not to your test for whatever reason. You're looking at the list of deprecated keys and you are working your way down to the list of deprecated keys. So that's the only way that you would hit this mechanism at all ever. So if you have not enumerated the the the identity equivalent set in the first place, you're you're never you're never you're not gonna see this. And if there is a signature by the preferred key on the deprecated key, you're not going to know what semantics that means or you're not gonna be able to trust that until you have, again enumerated the equivalent set and identified that, no, this is the this is the actual preferred key at which point you're back into the you're back into the list of fallback keys, we've already is we've already defined and agreed upon. So I think
[01:17:00] Daniel Huigens: Yeah. But but if if you have destroyed the key material of the old key, then then you don't want people to use the key under any scenario. Right? Like, even if they haven't looked at the replacement keys,
[01:17:14] Andrew Gallagher: then it's still It could be. Yeah. Sure. But if you've lost the key material, then it might or if you've destroyed the key material, it might be fine to validate old signatures, historical signatures made by this key or it might be fine to pick up an old stale copy of your key ring and go, you know, refresh from the Internet and find and and thereby upgrade to the the to the preferred key. Then once you get to the preferred key, the preferred key says, yeah. By the way, don't fall back to that, you know, because Yeah. I I destroyed the key material. So it's kinda like a it's a ratchet. So you can't
[01:17:51] Daniel Huigens: But but that shouldn't be used for for encryption in any scenario. Right?
[01:17:55] Andrew Gallagher: You shouldn't create new encrypted messages to this key. No. That's that that and that's the only thing this is for. For identity equivalency, all signatures generated by all the valid, you know, not hard revoked keys in this set are still valid. They've all kind of they've signed each other's, you know, the the, you know, the fall got the the the replacement key records that form the set and, you know, one of them is equivalent to the other for for those purposes. But purely for the purposes of encryption subkey selection when you're generating a new encrypted message, we would like to be able to first, we already have a a preferred order that already exists in the spec. All that we're saying here is that some things will have priority negative priority or or, you know, do not do not use priority effectively. That's what this is. Anyway, this going on. Next slide please. Sorry. So aside from that spanner in the works, we do still have a couple of outstanding questions about how to generate these equivalents groups in SOP or in sets. I keep mix I I, you know, I keep mixing up groups and sets here. Sorry. And there is a a related ticket in in soft about the encryption subkey selection as well. So we we do we do need to to to nail these down in order to be able to write proper, interrupt tests for the interrupt test. So, yes, if we we we should revisit these please before before IETF 127 and have some some kind of way forward. And the other question then is, is there anything else that is required other than getting, you know, the the interop test suite working for this. Thanks. The last slide is just the the usual links.
[01:20:14] Daniel Gillmor: Alright. There's some discussion in the chat about the possibility of another way of representing that, like treating a revocation signature from the replacement key over the fallback key as valid a valid key revocation. So that would permit the same semantics, I think, while using existing mechanisms and not changing the replacement key mechanism. So maybe that's another way that we could achieve the goals that are described without so, you know, maybe maybe folks wanna produce some MRs that go in either of these two directions and bring them to the group and say, hey. Here's what we're considering. That would be useful.
[01:20:53] Andrew Gallagher: Right. I will check I will check out the chat. Thank you.
[01:20:58] Daniel Gillmor: Thanks. We have ten minutes left here. There's three more talks that people submitted slides for. This one is for Heiko just to raise it while we have a chance. Heiko, take it away.
[01:21:15] Heiko Schaefer: Right. So this is another draft that deals with hardware devices, secret key material hardware devices. Next slide, please. So the goal is to use existing hardware for keys that are beyond version four, so especially version six keys. The motivation in my mind is there are literally millions of devices that people have that can do curve two five five one nine cryptography. Some of them are over 10 years old, and using those for v six keys would be nice. It's also possible that in the future, OpenPGP card devices will support post quantum mechanisms that are usable for OpenPGP. It's also possible to have curve four four eight, so it would be nice to be able to do v six keys with these cards. Next slide, please. So the reason why there is a problem at all is that these devices have a 20 octet field for an identifier that identifies the keys that's in a key slot, and that was spec for version four fingerprints. There is no explicit version. The version is implicit. So on these devices that have these constraints, we cannot store v six fingerprints because the field is too small. Also, there is no way to put a key version in a separate location. So this draft is a suggestion for, like, what to put on these devices that exist to put v six keys on them in an inter interoperable way. Next slide, please. So purpose. We've already had some discussion on the list, and from that, I learned that we need to be clear what this hopes to achieve and what it doesn't hope to achieve. It does not hope to achieve well, first off, it's not required. This field is not required to do cryptographic operations. It's entirely informational in terms of cryptographic operations. And then the second nonpurpose is the mechanism does not guard against attacks against malicious devices that are contain just wrong information or might even, like, not implement the protocol correctly and lie about things because some attacker built it. So it's like this is out of scope for this draft. This draft wants to do two things. It wants to have users that trust their device, that they can have an unmediated visual inspection. They can look at the output of this identifier field and reason about it with their brains without needing additional software. And the other point, the final point here is facilitating use of a provisioned device, for example, on a new computer. So if I have a card, I plug it in. I want my software to do something sensible with the card, and this is where this identifier can be useful. So just to recap, for v four devices, like, fingerprint would be found, and then an application could, for example, do a key server lookup and find a public TPK certificate. And we want to have this kind of property for v six keys also. So we want an application to be able to conclusively detect that a key slot on a device is used for OpenPGP. It could be something else, but we want to be able to detect this is OpenPGP. We want to be able to reconstruct the full public key packet from the information in that field. And based on this reconstruction, we can do lookup, for example, on a public key server by the full v six fingerprint. Next slide, please. So the scheme that the draft proposes, it has iterated a little bit. Now the suggested encoding is to have if it's above four, to have first a block that is called version marker that consists of a bunch of zeros and one octet version, 12 octets altogether, and then to have a fingerprint prefix that uses the remaining eight octets. So this is the same as the key ID for v six, but if we imagine we had v seven keys, we might not have a key ID, but we could still do the same thing. We could still use eight octets of fingerprint pre fingerprint prefix. My god. So having this padded version marker limits the subset of the namespace in this 20 octet field that we're touching with this scheme. So we're limiting the spillover of v six keys into the v four space on these devices. So applications can sensibly assume that if there are 11 zeros, then it's probably not a v four key with a lot of zeros in the fingerprint even though in theory, could be. But, like, the more separation we have, the less applications need to second guess which version is encoded on the card. So the goal of this scheme is to have properties that are analogous to the established v four keys even though it has to into different encoding to achieve this goal. Next slide. So as an example, I'm showing the v six fingerprint of the v six TSK primary from RC9580, and I've underlined the prefix, which is also the same as key ID. And then we see on a OpenPGP card device in the 20 octet fingerprint, formerly fingerprint, now identifier field, we'd have a whole lot of zeros followed by a six and then followed by the fingerprint prefix. So this is what that would look like on a card. Next slide. So this again, maybe we don't need to go over it in-depth. I've I think I've made these points in an earlier slide. So the users are easy casual inspection for users. We want to look at it and see, okay. This is probably v six, and, oh, I recognize the key ID, and I remember what this key is now. The second bullet point is being able to reconstruct a public key packet based on just the information on the card, and then the sub bullet points explained how exactly that works. Skipping over those. So the third big bullet points is finally reconstruction. Right. You giving a lookup. So yeah. Status next steps. We have experimental implementations. One is by me, and one is by Paul for PGPainless. And I think it would be useful for the working group to consider adoption because this is a draft that would suggest how to interoperably use these existing devices for v six keys. I think that would be good. Next slide. Yep. Questions, feedback link.
[01:28:00] Daniel Gillmor: So as a chair, I will note that the IETf does not own the open PGP card specification that this attempts to fix. We can't actually directly fix that implementation. This would just be like a writer where we're saying, hey. This doesn't appear to be usable with what we've got, but here's a way to make it usable. I don't know that we're ready to adopt another draft right now. We've got five open drafts, but some of them are on their way towards being done. But it would be good if folks, you know, are interested in in this. This doesn't actually touch the normal wire wire formats at all, but it could just be a statement of intent from the OpenPG working group if we were to decide to adopt it. So I don't expect it to be adopted right now, but just giving folks a heads up that this is underway. Anybody else wanna talk? I'll look for a queue, but we are we have two minutes left. Andrew, I don't know if you wanna do one of your two other presentations in the two minutes or if we should just hold those for later.
[01:29:00] Andrew Gallagher: If you could throw up the the validity one, please. I'll very, quickly describe what it's about. Yes. This one, whole free validity. So this is something that we have discussed before on the list, but this is a proposal. There are there are emails in the list archives that that summarize the the reasons behind this, but the idea is that that, particularly, subkey binding signatures and direct, and direct key signatures, they should the signature creation time we propose should no longer be automatically assumed to be the start of validity time. The reason for this is that, you want to you will if you create multiple self signatures over a period of time and then maybe you throw you you can't throw in the old self signatures because then, historic your historical signatures made by that particular key or subkey then become invalid, as viewed by your correspondence. So if you go to the next slide, please. This is implemented in HockeyBook right now for SLH-DSA keys because DSA, self signatures are enormous. It only applies to self signatures, it does not apply to third party certifications and it does not apply to revocations. Next slide please. So the questions are, there is a draft which is on the next slide, but we need to make a decision about the scope of this draft. I would be very, very happy if the scope of this draft could be kept as tight as possible. I would like to be able to say that revocations are completely out of scope of this draft and will be addressed in the next or some subsequent draft. And if this could be kept small and tight, I would hope that, we would see fit to adopt this at some point in the near future. So that is me. Thank you. Daniel?
[01:31:14] Daniel Huigens: Yeah. So I I know we have, like, minus one minutes for for comments. But I wanted to say anyway that I mean, I've said in previous meetings that I I I think the the framing of that changes is not quite correct in my view because, like, the interpretation that our implementations have today is not that the signature creation time defines the start of the key validity, but rather that in the absence of a valid binding signature, we don't know what the key can be used for. Right? So if we want to define that the key can be used before the binding signatures that we know of are created, then we should say something about what the key can be used for at that time, and we can either verify the the binding signatures at the current time and see, like, what can the key be used for now, then we assume that it could also be used for the same thing in the past. Or maybe we say that the key can be used for everything by default. But, I mean, we should say something there. Right? And I I'm I'm still not, like, a 100% convinced that that change makes sense, but I I do recognize that, like, for SLH-DSA, we don't want to have a thousand binding signatures for sure. So, I mean, doing something, I guess, makes sense.
[01:32:41] Andrew Gallagher: Okay. So yeah. So, again, we can we can tweak the language to make it better fit perhaps the the the the the kind of headspace of, existing existing implementations, but I would really want to get to what I'm quite results focused in this. So whatever gets us to the point where we can clean up old signatures safely is good by me. Thank you.
[01:33:10] Daniel Gillmor: Thanks, Andrew, and thanks everyone. Sounds like there may be more considerations to write up on this draft, but I'm glad to see it progressing. I do think we need something to address this. So that's all we have time for today. Please take other questions to the list. Thank you for a good discussion, and it's great to see the work progressing. I don't think we have any concrete action items to take where the from this. We just had an adoption, and we had some stuff moving along. But stay tuned on the list, and I we we'll be scheduling a meeting for next IETF 127, which will happen in San Francisco. Hopefully, some of you will be there either in person or remote. Not hearing anybody else. I'm gonna call it, and thank everyone for being here. Talk to y'all soon.
[01:34:09] Daniel Huigens: Thank you. Bye bye.
[01:34:11] Heiko Schaefer: Bye bye.