Session Date/Time: 17 Mar 2026 06:00
Russ Housley: We have already gotten a note-taker, so we don't have to spend time doing that. And we have time now. Let's begin. Tim, are you going to do the intro or me?
Tim Hollebeek: I was going to let you do it.
Russ Housley: All right. Let's see if I can take... You've got control. I'll just have to say "next slide." All right, so, next slide, please. When you registered for this meeting, you agreed to the Note Well, so this is a reminder that we're going to treat each other well. We don't have to agree with each other's ideas, but we have to treat each other with respect. And we need to make sure that if there's intellectual property that needs to be disclosed, that you do so, and that we are all going to follow the other IETF regulations and things that make these things more productive. Next slide. Just a reminder for everybody who's remote, if you're not speaking or chairing, please use a headset and mute yourself. And people who are in the room, please make sure you've brought up the onsite tool, because that is how we're going to manage the mic line. So if you're not logged into the Meetecho session, you can't get in line to speak. Next slide, please. These are the resources for today's session. The agenda and the slides have already been uploaded. The notepad is where the minutes are being taken, and Zulip is what's running the chat, and there's the two links for the onsite and the remote participants. Next slide. So we've got a pretty full agenda, but not as bad as it has been in the past. So this is the pass for agenda bashing. We're going to just talk about what the recent publications are, which things are in the RFC Editor. Next slide. Things that are with the IESG, things that we have active discussion for today. Next slide. And the things that people would like us to consider adopting, one of which has got an ongoing adoption call, or recently ended. So, is there any agenda bash now that you've seen the agenda?
Speaker 1: Post-haste, I would like to bash again. I think almost all of these documents in the... that you say are in the editor's queue are actually published RFCs.
Tim Hollebeek: If you look at the agenda online, you'll see that the agenda online has a couple of those corrected. Yeah, so you're right, the list is a little bit longer than on the chair slides.
Russ Housley: Correct. We were updating a whole bunch of stuff at the last minute there on that regard. So what I was going to hope to do is take agenda blocks two and three and say: these are the things that were recently published and with the RFC Editor. Are there any of those that need to be discussed? That was the answer I expected. Okay, so let's turn to the "with the IESG," which is one slide back. I suspect most of these don't need discussed as well. Tim, can you... there you go, thank you. The composite signatures documents are with the IESG. Are there any updates that need to be shared with the group on either of the composite signature documents?
Tim Hollebeek: Nope, they're good.
Russ Housley: Okay, thank you. All right. The... Corey, the CRL key usage validation document? Is there anything we need to talk about with that one?
Deb Cooley: Isn't that in the editor's queue?
Russ Housley: Sorry, I can't hear Corey at all.
Corey Bonnell: Okay, there we go. Yeah, the mic works better when it's turned on. Um, yeah, so both the CRL key usage validation and the MAC address draft are both in the RFC Editor's queue. So we incorporated all the feedback. Um, thank you Deb for the guidance you gave for both documents.
Russ Housley: All right, cool. I was going to say the MAC address, when I didn't know the other one. All right, so that brings us to the active documents, and I think all of these have presentations or some form of status. So Mike, I think you're going to talk about CSR attestation?
Mike Ounsworth: I hope Hannes is talking about CSR attestation.
Russ Housley: Ah, okay, because that's who was going to talk. Tim, can you bring up that slide deck?
Tim Hollebeek: I've looked at the slides. I can do them if... I thought Hannes was presenting.
Russ Housley: Well, Hannes is in the room. I'm not seeing them in the slide list. Am I missing it? Oh wait, did we just not submit them? That's entirely possible. That might have been an omission. Oh wait, yeah, no, I see the... yeah, I see the Attestation Key EKU, but that's a different one.
Mike Ounsworth: That is a different one. Okay, I think we just never submitted slides. Oops. I will sit down.
Russ Housley: Okay, so do you... Is there something you need to share? If, we'll move you to the end of this so you can... we can work with that while we're on the next document.
Mike Ounsworth: Um, I mean, yes, this has had a lot of churn since Montreal. The design team was formed and convened, we had an interim, there's lots of updates. Oops. How do you want to handle this?
Russ Housley: Please send us some slides through the data tracker and... I had a conversation with Hannes about the next document, the attestation freshness, and he says that was totally dependent on this first one, and since it is not...
Mike Ounsworth: Okay, yeah, yeah, we have slides. Let me get off the camera and go do those.
Russ Housley: All right, go do that. Okay. Corey, draft-ietf-lamps-certdiscovery. You want to do that one?
See slides: draft-ietf-lamps-certdiscovery
Corey Bonnell: All right, all right, this time turn the mic on. Okay. All right. Uh, we'll be talking about draft-ietf-lamps-certdiscovery. Uh, oh, and here's the clicker. Can I control this? Yep, all right, looks like it's... all right, we're all good. Uh, yeah, so I'll be talking about certificate discovery. Uh, there's our draft. Uh, we've made some progress since our meeting in Montreal. Um, we added David Hook as a co-author. Um, one of the things we mentioned at Montreal is that we're no longer going to work on Chameleon. Um, David Hook contributed significantly to that draft. Um, we see certificate discovery as incorporating some of the benefits that you get from Chameleon but without the complexity. Um, and he brought a lot of good ideas there, and we think he'll also provide good ideas for this draft, so we wanted to bring him along. Um, we fixed a couple of ASN.1 bugs that were pointed out by various folks, such as Russ, on the list. Um, also too, to avoid any, I guess, confusion in terms of key purposes, like using the word "purpose," we changed to "intent." Um, some people aren't very keen on that, so we might revisit that again at some point, but at least some folks have preferred a different word. Um, we're also getting in some great feedback from Daniel Van Geest. Um, they're coming through on the GitHub comments. Uh, we're working through some of those, we've already have some solutions put in place. Um, we need to get agreement though from Dan and the authors. Some of the things are discussed is like if the primary certificate fails certification path validation, can you use the pointer to the secondary certificate? Um, and if you do, you know, what security issues arise and are there cases where you don't want to do that? So I think we need to work through those for each of the different intents. Um, also we're working on example certificate generator. We think it'd be great if we had some working examples in the document itself, um, that people can go and, you know, plug them into their tools to make sure everything's working right. Um, we've figured out the certs we want to generate and include as examples, we just need to finish writing the scripts. Um, we made some good progress at the hackathon this weekend. All right. So the next steps that we have, um, is resolve the remaining open issues from Dan. Um, we also got some feedback or questions from Sarat on SPKI binding. It sounds like they were interested in potentially using some of the mechanisms in Chameleon to save storage space. Um, so we're going to work through those to see if we can accommodate that with this draft and maybe potentially add this SPKI binding. Um, we're going to plan on finishing the generation scripts, and we'll be pushing out a new version, um, and then hopefully working group last call with a target before Vienna, if not sooner. Uh, any questions? Comments? I see Falco's in the queue.
Falco: Yeah, so I must admit I haven't looked through the GitHub issues. But my question is about how you imagine the agility aspect brought in through this extension, because it's, as it says, it's just a discovery mechanism. So, any idea of switching to a different certificate path, at least in a synchronous protocol? I don't see how this could be possible. Can you elaborate on that?
Corey Bonnell: Yeah, so it might not be within the same operation, but there's a couple of different intents. But one is, um, I have your encryption key certificate, I want your digital signature certificate. At some point that would might be useful, so I can go and follow that pointer within the encryption key certificate, grab your signature certificate, um, and I'll be able to verify any signatures that you send along. Uh, that is one use case. Another one is you might have like your, you know, your traditional RSA key certificate and I want your ML-DSA key certificate. Uh, again, for potentially a future operation. Um, I can go and follow the pointer and retrieve that.
Falco: Okay, these use cases I understand. But in the draft, it says something about a server checking which certificate the client is using mostly, and this to me suggests that there is the idea that somehow in a synchronous protocol, you can use the... this discovered certificates for an alternative... yeah, as an alternative in the same protocol run, and I don't think this is possible. I mean, I don't want to necessarily discuss this here in length, just maybe I can also follow up on the list, but this should be entirely clarified in the draft. Use cases, examples for the agility, and I'm only talking about the agility use case. So I think this needs more clarification. What do you imagine? What is possible? What is not possible? Yeah, so this would be my suggestion.
Corey Bonnell: Okay, yeah, we'll take a look at that. I didn't think there was language that explicitly said that that's possible, but we can revisit.
Falco: Okay, thank you.
Corey Bonnell: Anybody else? All right.
Russ Housley: Thank you, Corey.
John Gray: It's John. I was just going to say, Corey and I got the first interoperable kind of beginnings. Corey mentioned the scripts that were written in that, but two completely different implementations actually work together, so anyway, positive stuff going on there. Just wanted to mention that because it was exciting whenever we get interop stuff happening, right? So anyway, thanks again Corey for presenting.
Corey Bonnell: Yep.
Russ Housley: Okay, in the lead-up to this meeting, I have not heard from Henry. Is he here to talk about CAA? Okay. Then we're going to skip that one too. Um, Mike put into the chat that there will not be slides on CSR attestation at this meeting. We'll talk about when we're going to deal with that. So we're going to move on to the composite KEM documents.
See slides: pq-composite-kem AND cms-composite-kem
Daniel Van Geest: All right, can you hear me?
Russ Housley: I can.
Daniel Van Geest: And I have slide control. Okay, so um, the larger composite ML-KEM document authors have asked me just to add a slide into my presentation for the draft-ietf-lamps-cms-composite-kem, so I will be presenting both of them. Um, first, just one update from composite ML-KEM. So the status, uh, people might recall from LAMPS 124 IETF meeting that there was discussion between LAMPS and CFRG composite KEM authors. Uh, that has been resolved, and the draft has been stable since then. The only thing that was waiting on was a proof of security paper that was recently published, uh, mentioned in the chat, published by Deirdre, Mike, Sophie, and Douglas. Um, so they are going to update the draft with that, um, fix a few more editorial issues, and I guess the question is: is working group last call already done now that this has been finished, or does anything else have to happen, uh, procedurally?
Russ Housley: So, the... we did a working group last call on the certificate one, but not the CMS one, I believe.
Daniel Van Geest: That is correct.
Russ Housley: Okay, so that one we were waiting... the certificate one was waiting just on those proofs. Those are now available. I think the only thing you needed to do was update the reference to point to that new paper.
Daniel Van Geest: Okay, perfect. Yep, they have that... they have that pending, so once that's done...
Russ Housley: Okay, so that we can send to the IESG as soon as that reference is updated, and we can start a working group last call on the CMS document, uh, next week?
Daniel Van Geest: Yep, that's coming up in my next slides, so composite KEM in... ML-KEM in CMS update there. It's a very straightforward application of composite KEMs to CMS. Um, we have effectively just taken RFC 9936 and changed ML-KEM to composite ML-KEM. Not 100% true, but it was a very straightforward... because it's a very straightforward draft, we could reuse a lot of the text from that RFC. Um, what we've said is, um, because we need some algorithms for interop purposes, uh, we're saying the KDF that must be supported just for interop purposes—you may use others—is HKDF with SHA-256, and then AES-256-WRAP. Um, not AES-128 is not included in there because ML-KEM-512 doesn't have a composite, only ML-KEM-768 and 1024, so AES-256 matches. Uh, Victor, would you have a question? Victor, if you're talking, we can't hear you.
Victor: I have to unmute the mic, that helps. Um, all right. Uh, so for the certificate use case, presumably that's just for the identity key, right? Standardizing the format of the public key for a composite, right? You can't actually sign the certificate with ML-KEM as far as I know.
Daniel Van Geest: That's correct, it's just the SPKI.
Victor: Right, just the SPKI standardization. Fine. Um, so moving right along, um, I've always complained about what I consider to be misguided attempts to align the security levels of each and every algorithm in every combination. Uh, so you know, previous RFCs have said that when you're using ML-KEM-this, then use, you know, a particular SHA variant, and when you're using a different ML-KEM, then use a correspondingly stronger or weaker SHA variant. I think all of that is a bad idea. Uh, we really should be specifying the components independently, and the strength that you get is the strength of the weakest component. Locking things down so that only certain combinations of components are valid just reduces interoperability and makes it harder for users to construct working configurations. So I would not like to see AES-128 excluded here just because, you know, the... the KEM is stronger.
Daniel Van Geest: It's not. So this is not saying that you must, um, combine these algorithms together. It's just that an implementation must support them, uh, basically be able to receive a KEM blob, um, in order to, uh, parse them for interoperability purposes. But the draft... and this is actually... we're doing this because we kind of have to follow what's in RFC 9629 to say, to get a minimum level of desired security, the... the levels must match. Um, but we're not mandating that you have to use these algorithms. You may use other algorithms.
Victor: Right. It's just that, again, levels matching... yeah, bad idea. Let's specify all the other AES variants too. This is just pointless. You may disagree and ignore me, but my take is, uh, the interoperability should include AES-128, and maybe even AES-192, which isn't very popular, but there's no reason not to specify those.
Daniel Van Geest: So would you say the same about any of the HKDF variants, or just the AES one?
Victor: Uh, if we're including AES as the only, you know, required cipher, it should include multiple variants of AES. Uh, uh, yeah. Uh, regardless of which ML-KEM is the chosen KEM. Uh, again, subject to others, you know, I might be in the rough. So you know, please ask on the list if you're... if you think I'm blowing smoke.
Daniel Van Geest: Okay, I will ask on the list. Thanks. Um, okay, next. So we do have to publish an update to resolve Victor's question here. There was some reference changes that had to get moved, and now that the Kyber CMS... or Kyber certificates draft is published, we'll have to update the reference for that. Uh, and then that's it. We'll ask for working group last call.
Speaker 2: Yeah, I got confused by the previous comments. I agree that you should not... with the previous comment that you should not mix... you should not match, try to keep the same security level. You should keep it simple, and then you get the security of the weakest algorithm. But then Victor said that you should support all AES variants, if I understood correctly. I would disagree with that. I think you should just pick AES-256 and then use that, if that makes things simpler.
Daniel Van Geest: So I am... I'm taking a look at RFC 9629 right now, which is a KEM recipient info. Uh, in security considerations it says the KDF should offer at least the security level of the KEM. The choice of the key encryption algorithm and the size of the KEK should be made based on the security level provided by the KEM. The key encryption algorithm and the KEK should offer at least the security level of the KEM. So we have just been following considerations from there. Um, but yes, it says "should," so we can say, "Okay, implement all this for interoperability." Okay.
Scott Fluhrer: Okay. Uh, there was the argument that we should... should support every single possible AES variant, and I... because of interoperability, I would disagree with that. That's exactly the wrong thing. Consider TLS 1.2 cipher suites, they're ridiculous. Uh, if we just do AES, for example, just do AES-256 everywhere. Uh, is that overkill? In many cases, yes. Who cares? It is cheap overkill. Thank you.
Daniel Van Geest: Thanks, Scott. Victor, you're back in the queue.
Victor: Uh, yeah. Uh, so if there's just one particular variant of... of an algorithm, that's actually probably fine, but it's, you know, it's not because we need to keep everything in lockstep. Uh, right? My main objection is when we then specify, you know, use this AES for this KEM and a different AES for a different KEM. I really far more object to attempts to lock down, you know, separate components when multiple ones are possible, and we have to simultaneously make adjustments on the... on the cipher side that match the KEM side. If there's only one cipher, I'm fine with that. The rationale should not say, "in order to keep, you know, whatever," it's because this is the required AES, and if you want to try a different one, you can. Uh, not because... the... right. So in other words, the restriction isn't that, you know, you have to keep them in sync, it's just that the... the only one that's required is AES-256. That's okay. Uh, right? It's more the reason than the... than the outcome that I have a problem with.
Daniel Van Geest: Okay. I mean, it happens to be that the level matching that we do because of RFC 9629 leaves us with one single encryption algorithm, one single KDF, so we can remove that reason and it sounds like you might be happy?
Victor: Uh, yeah. I was just too late with, you know, objecting to that other RFC where I think there were mistakes made in its design, and I don't want to repeat them here. But we can certainly specify just one AES, that's okay.
Daniel Van Geest: Okay, so I'll... I'll tweak it so that it removes the rationale, I believe, and then if we keep the same... people can... people can do other ones as... I'll make that clear. Um, but this is the default one for interop. Okay, the queue is finished then, I am finished, but I'm presenting the next one, so I'll stay here.
Russ Housley: Okay, but uh, just want to capture that as soon as you get that out, we can do the working group last call.
Daniel Van Geest: Sounds good.
See slides: Best Practices for Signed Attributes in CMS SignedData
Daniel Van Geest: Okay, I have control. Um, so this is an update to the constantly renamed best practices for signed attributes in draft-ietf-lamps-cms-euf-cma-signeddata. Hopefully, this is the most clear title so far. Um, also a short update. Uh, since adoption, um, based on Russ's suggestion and discussion with Carl Wallace, uh, added a new mime-data content type, and the best practices will say that any new uses of CMS SignedData must not use the id-data type. New uses where the content type is MIME should use the mime-data type. Um, any bis documents for... for protocols which use CMS should deprecate id-data or provide rationale for not doing so. Um, updates that do keep id-data should specify that signed attributes is always required or always forbidden, just for consistency. And then recipients should perform the expected content... or, yeah, should expect... should perform verification of the expected content type and existence of signed attributes. Um, there were some mitigations for what to do if you stay using id-data. Um, that remains the same from the previous version of the draft. Um, we updated the... the security considerations. Um, Falco did, um, adding a use case for signing or... adding the... updating the case for signing and encryption. And then, uh, Falco pointed out that using signed attributes because you're doing a hash of the signed attributes loses the independence from the assumptions of collision resistance that we get in some more modern signature schemes like EdDSA, LMS, and XMSS. Um, so it's just something for people to be aware of. Uh, added an ASN.1 module, and then added IANA considerations. So, we have some very small updates to make, and then we believe the draft is ready for working group last call, so we will request it once we publish the next update. Victor.
Victor: Uh, just a quick question. I've seen multiple implementations, uh, get confused between the fact that there's a message digest in the signed attributes, uh, that represents how the... the hash was derived that's in there, and then again with algorithms like RSA, there may be another digest that was actually used to sign it, and the two don't necessarily have to line up. Uh, and then problems ensue when, you know, implementations get confused about which digest is which. Uh, and I'm wondering whether it's appropriate in this document or elsewhere to say something about: don't... don't use, you know, SHA-256, you know, in the signed attributes and then SHA-1 in the RSA signature, or vice versa, or any other unexpected mis-uh-combination where the two really are very different. Um, I don't know if that's appropriate in a document like this that's kind of clarifying use of signed attributes, or whether it's a whole separate issue. Uh, but I think it's at least a point where uh, robustness might not be expected if you mix and match your... your digests at the two different layers.
Daniel Van Geest: I don't think it's a bad idea, maybe Russ has an opinion.
Russ Housley: Well, um, this is, uh, written at a higher level where it applies to all signature algorithms. Um, it might be worth noting in security considerations that when RSA is used, the part of the data that is encrypted includes the, uh, OID of the... of the hash function, and that needs to match. But it's... it doesn't affect the other recommendations that are in this document.
Victor: Indeed, it's a separate, you know, kind of... kind of layer, but uh, could be helpful to implementers, I thought. Uh...
Daniel Van Geest: Would you, Victor, have suggested text for that?
Victor: Okay, yes, I stuck my neck out. Uh, thank you.
Daniel Van Geest: Okay, that's it for me.
Russ Housley: Okay, at this point, we've reached the end of the block of active documents and moving on to several that are up for potential adoption. So the next, uh, one is from JP on attestation key EKU.
See slides: Attestation Key EKU
JP: Hi everyone. Um, so I tried to reach adoption back in November, um, and we... we reached quite a bit of friction at that point, so um, I've come back. Uh, we've made quite a bit of change, changes since November, so we'll talk about that. Uh, what I'm looking for is a new key extended usage, uh, for attestation keys. This is a bit of a repeat of November. Um, there are already attestation keys out there, there's already prior art. Uh, most of them is TPMs and DICE. They already have use EKUs, uh, but through research, it seems that these EKUs cannot be reused for the purpose that we need at this point. So after the meeting at IETF 124 in Montreal, a number of suggestions were offered. Uh, we're looking at the use of policies, use of a new critical extension. Um, we met with the authors. After considerations, we decided to narrow the scope of the draft. It looked like the way that the draft was written in... in the prior version, it was too prescriptive, and that's why it was introducing confusion as to the aim of the... of the work. Uh, so instead, uh, we've decided to let the CA make the decision as to the mixing of EKUs. At that point, we had said there can only be one EKU, and that was, like, difficult to... to police through, like, EKUs or policies. So instead, we've... we've changed, we've introduced implications sections for the CA, the verifier, the attesters, and the cryptographic modules. And that gives us the opportunity to point to the proper references. Um, so the implications for the various roles, so basically, as far as a certificate authority is concerned, uh, the CA must also ensure that the attester is the only entity that controls the key. So in the concept of attestation, there's a... there's a need of non-repudiation, and so, uh, we addressed that. Um, for the verifier, they may reject the evidence if the X.509 certificate does not contain the appropriate key purpose, the extended key usage that we're proposing. Uh, the implication for the attesters, and... and here, uh, this is a bit of a controversy. An attestation key, the authors feel like it must be used by an attester to only digitally sign the evidence. But it was raised in Montreal that we... we might want to create a CSR for that key, so this key might be used to sign something other than evidence. Um, so we've put a "should" in here. And the implication for the cryptographic modules, uh, obviously the modules need to provide the appropriate service, you know, to... to accomplish the recommendation proposed in the spec. So, uh, we've updated the... the document. Uh, we're coming back. We would like to ask for adoption. Uh, we have a... we have a draft right now as part of the RATS, which is evidence encoding for HSMs, which would be dependent on... on this EKU. Uh, so the work is split between the two groups, as the EKUs are really a LAMPS concern and the... the evidence encoding is really a RATS concern. So that's it for me. Uh, these are the pointers if you want to find the work. Um, I'm ready to entertain questions.
Mike Ounsworth: Hi. Um, I got a chance to talk with JP for about an hour, uh, last week, and I actually think a draft like this is necessary. The problem with the current draft, from my point of view, is that it's heavily RATS-ized as opposed to being PKIX. Um, there are a number of things that are in there that are problematic when you're just trying to look at getting a key enrolled by a CSR, you know, getting... somebody who's looking at a certificate to do something useful with it. It's perfectly fine for RATS to say what they want to do on the RATS side, and it's perfectly fine for the CSR or for other things to do what they want to do with respect to that usage. It's probably not appropriate to go down one path in this document that basically eliminates other paths. So, um, there's a couple of other things that are actually technical that need to be fixed, um, related to, uh, how you actually do attestation. Signatures are one way, um, but there's also proof by decryption, which is used in a couple of other systems. So I don't want to eliminate those, and I want to make sure that we don't prevent those from going in that... in that space. And there's a bunch of other little things, but again, that's where I'm going with this.
JP: Thank you.
Mike StJohns: I'll express my opinion on whether to RATS or not to RATS. Um, the point about not over-RATS-ing, I think was sustained on the CSR attest document, but this EKU document is attempting to register an EKU for the wire format that we're specifying in the RATS working group. Like, this is a subordinate document to a RATS working group document, so I don't understand the objection to RATS-ifying a thing that is subordinate to a RATS thing. Over.
Mike Ounsworth: Um, yeah, and I don't actually understand that. This is a document that is marking a certificate that says that the certificate contains a key that can be used for attestation, period and the statement. It's not the key in this is a particular type of attestation. That's something different, and if you want to do that as an EKU associated with something you create over in RATS, perhaps. But this was supposed to be a more general purpose than I think... at least that's the way I understood it the first time this came around. So...
JP: If making this EKU specific to the PKIX evidence ASN.1 structure that we're defining in RATS would make the objections go away, I could consider doing that. I have to talk to my co-authors, but to me, that would seem like a friendly suggestion.
Mike Ounsworth: Um, what do you mean by that?
JP: Uh, so if we say: this EKU means that the attester will produce the PKIX evidence structure (see RATS document), rather than trying to say...
Mike Ounsworth: No. No, in that case, in that case, you might as well just put the EKU as part of the RATS work, right?
JP: No, but... but RATS doesn't issue EKUs, LAMPS does. That's why we have two documents. Like, the EKU registry is owned by LAMPS, we have to do it here.
Mike Ounsworth: Okay. That's what I thought we were doing. I thought we were just... just getting an EKU for our RATS thing. I didn't realize we were trying to boil the ocean.
Russ Housley: Let's go with Victor.
Victor: Just a quick sanity check. This EKU is only for the identity certificate, right? It's not expected to appear in intermediate or root CAs?
JP: That is... that is correct, yes.
Victor: Uh, because I've already run into issues with DICE where they've specified various EKUs as mandatory in intermediate DICE certificates, and this is now causing real problems. So we want to make sure we don't run into that here.
JP: Yes, they have four different EKUs and they're used at various stage of... of the life cycle of the device. Yeah, that's why I'm trying to not touch those at all. Yeah.
Mike StJohns: That was helpful, Victor. Thank you. And so, Victor, to make sure I understand you properly, your suggestion is: this should be only for EEs, not for CAs, right?
Victor: Absolutely, yes. Otherwise, expect lots of problems and pain.
Mike StJohns: Great. Wonderful feedback. Thank you.
Richard: Sorry about... sorry about that. Um, you came to LAMPS because you wanted something in this particular OID arc? We don't care about OID arcs, right? It's just going to be a random string of bytes. Just do it all in RATS.
Mike StJohns: I don't think RATS has an OID arc, do they?
Richard: Well, then do it in somebody's private enterprise network OID arc. I mean, really, it's... they're opaque.
Russ Housley: I think they could even do a coordination with us and get it in their document.
Richard: Yeah, just do it there. I mean, if this is designed for that, then... then just do it there and say, you know, you send mail to, oh, I don't know if it's Russ and Sean, saying, "I need an OID," and they'll give you one.
Mike StJohns: Okay, if we don't need a... if we don't need a draft and we can just get an EKU OID some easier way, uh, cool. Awesome.
Hank: Does this mic... Yeah, okay. The other mic didn't work. Sorry, that took me to switch mics. Hey, this is Hank. Um, I think Hannes said DICE works very differently. Now I'm putting my, um, TCG co-chair hat on. There are a lot of TCG technologies. They all come with certificates. They work very differently. That's, first of all, correct. And they... some of them are for evidence generation. So the certificate identifies an attester, and the key usage is very specific, for example, evidence generation. That's an EKU. I have no idea why this is a problem. This is the right place. This is LAMPS. This is an EKU. It comes for certain certificates. We don't want to be ambiguous here. It's in the right domain. What is the exact problem that you have with this being an EKU and LAMPS? I'm looking at the chat and I'm listening.
Russ Housley: Um, as I'm understanding it from this discussion, Mike and others want a different attestation key EKU for each type of, uh, attestation type. Am I misreading that? Because you already have one for TCG, for the TPM. You want one for the RATS stuff that's coming over here, and then there may be something else coming along. I don't know.
Mike StJohns: That is normally how EKUs work, right? You... one protocol, one EKU. You don't want an EKU that lets you sign a bajillion open-ended protocols.
Russ Housley: That's right. Most... most EKUs are tied to a protocol or to a context.
Mike StJohns: Yeah, and the context I'm thinking of is certificate, but...
Russ Housley: It's always a certificate.
Mike StJohns: Yeah, okay. Yeah, the attestation stuff isn't a protocol, it's a... it's a data format. I... Right. Okay, I don't have any problem with you guys going off and doing this over in... in the RATS thing and call this a "RATS Attestation Key EKU," um, and make sure that it doesn't look like a generic thing. So I will... but I don't think it's a LAMPS thing. So yeah, no.
JP: Yeah, I think... I think that's a friendly suggestion because the idea of one EKU that covers an open-ended set of possible data formats was giving me the cross-protocol vibes, heebie-jeebies to begin with, so yeah.
Hannes Tschofenig: Yeah, I... as I said in the chat, I'm wondering, like, why do we need to move this over to... to RATS? Uh, because it seems like, again, one of those documents where, um, you get shuffled around between different working groups. "Oh, it doesn't fit here." And then the RATS group says, "Oh, but this is more LAMPS," because it's an extension, it's an extended key usage. That's a LAMPS topic. And then we get sent back and forth, uh, for such a totally simple thing.
Russ Housley: It is simple, Hannes, but I think putting the format and the EKU that goes with that format in the same document will help implementers.
Hannes Tschofenig: Okay. So you think RATS is the right place to do it then?
Russ Housley: Yeah, just work with the designated experts to get your OID in the right arc and you're done.
Hannes Tschofenig: Okay.
JP: All right. Thank you everyone.
Russ Housley: Okay, I'm making the next presentation because Stefan is on a train and uh, he thought it would be, uh, bad if he lost connectivity in the middle of the presentation.
See slides: One Signature Certificates
Russ Housley: So, uh, this work is in the middle of a call for adoption, and we'd just like to give you a quick update on what changed before we asked for that... that call. Uh, the basic characteristic is that this is designed to, uh, sign one document. The key pair is generated, a certificate is issued, the document is signed, and the private key is destroyed. The certificate never expires, uh, basically because the idea is the certificate can be validated at any time since there's no way the key can be lost or stolen. Uh, we're saying no revocation, and uh, it's bound to one and only one signature as, uh, you can even put the hash of the thing that was signed in the certificate itself if you want to do, uh, like the two-way binding. So basically we have the, uh, certificate extension that provides that binding. We don't think it should ever be, uh, critical, but uh, I suppose someone could do that if they were, like, being really, really crazy about it. Uh, the binding type, uh, which is there gives you an idea about what, uh, kind of thing you expect it was signed. Is it a CAdES or an XAdES or JWS or a COSE? Um, and so the document currently defines several of these and creates a registry so that new things can be added to the binding type in the future if it turns out to need additional formats. So since the last IETF, we, uh, dealt with some of the nits that were pointed out on the list. We added a security considerations, we added the IANA considerations. The, uh, one thing that has come up, uh, and not been resolved, and I'd like to start this discussion here, is we never found a really good use for the, uh, an X.509 extension that already exists called "Private Key Usage Period." And given that we know when the key is being generated, we know when it's used, and we know when it's destroyed, we could put this, uh, private key usage period into the certificate, and it may actually help someone, uh, who's using this in conjunction with a timestamp authority. Uh, just a thought. Not really hard over on it, just kind of thought maybe this is something we can leverage. It already exists and seems to make sense in this context. So the call for adoption started, uh, on the 13th, uh, I'm sorry, ended on the 13th. Um, I think Tim's going to say something about that.
Tim Hollebeek: Yep, the success of the adoption call was announced on the list this morning, I believe.
Russ Housley: Ah, okay. So lots of moving parts. All right. Any questions about the intents that we have going forward? Go ahead, Victor.
Victor: Uh, right. So I'm slightly puzzled, though I understand the desire to have it never expire. In practice, the effective expiration date then becomes the expiration date of the issuing CA, right? So in some sense, you know, if we're still verifying the certificate, it actually does have an expiration date. It's the expiration date of the validity of the issuer. Uh, so you know, what are we gaining by just not saying, well, the issuer should just set the expiration date to be the same as their own certificate and then we don't have to do anything special? You know, is there a difference here between lining up the expiration of the cert with the expiration of the issuing authority and lining it up to year 9999?
Russ Housley: Right. Um, I... you're right. I guess that's something we can look at in the next draft. Um, I'll write that down as something to discuss, uh, with Stefan, who is in the chat but is not on voice, so we will... we will discuss that one. Thank you.
Victor: Unless the hint really is a hint to the verifier to kind of store, uh, the fact that the certificate was verified, you know, initially and, you know, with their own signature, and then remember that indefinitely so long as they believe their key is secure. Uh, you know, that kind of information is sometimes relevant. Uh, I don't know if it's, you know, in scope here, but otherwise, yeah, I'm still puzzled as to what all of this really means. Anyway, that's all for now.
Sean Turner: Hey, um, so with respect to this private key usage period, it wasn't 3280, it got taken out of 5280, and 3280 was like: don't put it in, like, let it just be dead. I... It's dead and gone and went away. I think resurrecting it is probably going to confuse people. Maybe people wrote some code and took it out, I just... like, maybe we just find another way to do it if we really need the functionality or figure something else out.
Russ Housley: Well, it is still in X.509.
Sean Turner: Lots of stuff is in X.509.
Guilin: Hi, thank you. Uh, here is Guilin from Huawei International. I would like to know the content. The content is basically the fixed one, or it could be a has a kind of flexibility, you know, for one such certificate.
Russ Housley: So you're talking about this?
Guilin: Yeah, probably, because basically it means: okay, this is the certificate just to sign one document.
Russ Housley: That's correct.
Guilin: Yeah, have some content information. So I mean that, uh, whether this content information can fixed the document to be signed, or just a type of document.
Russ Housley: No, so the... you have the document in hand at the time you generate the key that you're going to, uh, then get certified, sign, and destroy. So that's the idea is that... uh, it's a single signature key, and so basically the next layer up, uh, could be a CA that's operating for just that user, or it could be a, uh, local RA that's running in conjunction with a CA that's... that's remote.
Guilin: Okay.
Russ Housley: So you know what's being signed at the time the key is generated.
Guilin: Okay. Okay. Uh, I also have a comment about the validity of the private key. I think it's better still to make it the valid for some time. It's not that long as the expiry of the public key. Yeah, either it is unlimited, or just the same expiry the day as the CA, because otherwise in some case, probably even such a certificate is issued, but the signer maybe never sign... never sign this document. For example, in some situation, he just changed his mind. But if the private key limit... uh, validity is very long, so some time later the private key compromised, so someone else can actually sign the document on behalf of the signer. So...
Russ Housley: I think you convinced me that Sean's right, we shouldn't do this.
Guilin: Yeah, yeah, doesn't matter. Yeah. I think so. Yeah. Uh, one more comments is the it's... it maybe better if you can give some more concrete example, like any kind of the particular service or even application is using this stuff. I don't know too much of the application for one... this is a little bit like a one-time signature certificate.
Russ Housley: So basically, uh, this is being used in, uh, several places in Europe already, where, uh, this is being used in conjunction with an archive service, but that way they're signing it and then archiving it right away, and, uh, so it... uh, Stefan is actually involved in one of those implementations.
Guilin: Okay, I will check more as well. Yeah. Thanks, interesting work. Thank you.
John Gray: Hi. Uh, yeah, we've... I've over the years come across use cases for, like, one-lifetime certs or whatever. But um, my comment was regarding again private key usage period. So you're saying that shouldn't be used? And then I looked through stuff that I found usage of it. But anyway, uh, that's good to know. And then a second comment: um, the lifetime of the CA. So if a CA key rolls, and you have link certs, or I guess the old with new, new with old, where you rekey, is it not possible to have a CA extend its lifetime? And if it is, then that could be a reason why you keep your infinite.
Russ Housley: Exactly, that's why I wanted to talk to Stefan, since he's actually doing code about this. I didn't want to, uh, suggest we were going one way and not... not talk to him.
Corey Bonnell: Yeah, I think John actually stole my thunder on that one. I mean, yeah, a CA certificate can be renewed, you can recertify that CA's key. So I think any language that's added to the draft that, you know, constrains the validity period of the end entity certificate is going to end up being overly prescriptive in some situations. So I think just leaving it with the evergreen, you know, not-after of 999... blah blah blah, I think is, you know, the easiest thing to do.
John Gray: Yeah, like we had a case for supporting, um, one-minute lifetime certs at one point, and the same thing in there, it ended up having like a time period of like, you know, the same thing, whatever the... the no date period that you had there. It was the same thing, because... yeah. So it's very... this is very similar to that use case that we seen multiple years ago, so. It's good that you're doing this now.
Russ Housley: Okay, great. All right, I guess Victor.
Victor: Um, just want to point out that in practice, I rarely see CA keys extended. Uh, you know, for the majority of cases, the CA just issues a new key and goes with that, uh, in part because older intermediate certs and so on tend to get cached, and then you're never sure which key the... the verifier will... or which certificate from the CA the verifier will have on hand when checking the validity. Extension and changing the dates is very fragile. Uh, so don't have unreasonable expectations about that working reliably, you know. Anyway, that's all for today.
Russ Housley: All right, the queue is empty, so we're going to go to the next slide. Uh, Valerie, you want to talk about FrodoKEM certificates?
See slides: Algorithm Identifiers for FrodoKEM
Valery Smyslov: Hello. No slides yet? Oh, okay. So, I'm Valery Smyslov, I'll talk about FrodoKEM in certificates. So, FrodoKEM is lattice-based, unstructured lattice-based KEM that is considered as a fairly conservative design, and it is being standardized currently, as far as I know, in ISO. I don't know the status of this standardization process. And also there is some interest in using FrodoKEM in internet protocols. So, and it seems natural, if a KEM is used in internet protocol, to have a specification how it is specified in certificates. So, that's the gap that we already have, and so this draft tries to fill this gap. Uh, so there is currently no specification for how it is represented in X.509 certificates, but OIDs are already allocated by somebody, it's not by me. And there is no ASN.1 module. So, what's in this draft? It's... first of all, its document structure and most of the text was impudently stolen from the draft-ietf-lamps-kyber-certificates, and many thanks to its authors, to Shupan, Jake, and Bas. So I just used the text and modified it in accordance to FrodoKEM specific. Uh, so OIDs were already allocated, so I just use them, and the structure of public and private keys is very simple: it's just octet string, with no funny things like in, for example, in Kyber with seed choice between seed and expanded keys and so on. So there is a definition of ASN.1 module, and there is no examples. Uh, I don't know currently whether it is no examples yet or permanently, because actually there is very simple ASN.1 wrapping, and if there are any examples, that it is just... must be an example of FrodoKEM itself that must come from more authoritative source. Uh, so I see no point to just copy-paste some official examples if they exist and just add a few bytes wrapping, ASN.1 wrapping. So, there is one issue that just I am concerned with. So actually there are OIDs allocated for both eFrodoKEM and FrodoKEM versions. Uh, you know that originally FrodoKEM was specified, uh, in the NIST competition, and then one attack was found, a multi-target attack that decreases its security levels, and authors quickly updated the initial specification, and so they keep naming it FrodoKEM, and the old specification that is vulnerable to multi-target attack is renamed to eFrodoKEM, with a comment that eFrodoKEM is still secure if private key is used no more than less than, uh, 125... 258 times. So actually it is one-time certificate, like one-signature certificate in previous presentation, but if one-time certificates make sense, I'm not sure that for the KEM certificate it makes sense, I'm just... I don't know. But since OIDs are already allocated, so the currently draft contains both FrodoKEM as a secure version for any number of private keys used, and eFrodoKEM, which is only secure if private key is used less than 258 times. So I don't know whether it is makes sense or doesn't make sense, or perhaps it is better just get rid of eFrodoKEM for certificates, it's a question, or just keep them because perhaps somebody need it. So currently they are in the draft. So actually that's all. So any comments and I don't know, perhaps it's a good idea to adopt the draft. What do you think?
Scott Fluhrer: Okay, Scott Fluhrer, Cisco Systems. Uh, about eFrodoKEM, I believe the security... the performance delta between eFrodo and Frodo is small, there is no real reason for eFrodo to exist, I would just drop it like a hot potato. Thank you very much.
Valery Smyslov: Uh, yes, but it's my concern. Just because OIDs exist, I included it into the draft. But I agree with you that it makes very little sense to use it. Uh, we can remove it. Remove eFrodoKEM.
Russ Housley: So, uh, we have a charter issue with FrodoKEM. Um, the... the LAMPS charter says that we can adopt PQ algorithms in our documents that are either approved by, uh, NIST or vetted by the CFRG. At best I can tell, we were... there was a FrodoKEM document in the CFRG that has stalled and is about to expire. If they don't publish it, I'm not sure we can. Uh, I mean, we've done other times, uh, had documents ready to go so that as soon as the other body approved it, we were ready to publish it, you know, immediately. Uh, and I'm certainly willing to do that, uh, but do you know whether the CFRG is going to move forward with their FrodoKEM document? And aren't you going to face the same thing in IPsec?
Valery Smyslov: Okay. So we should wait.
Russ Housley: Okay. Then...
Guilin: Okay, so I have two comments. Uh, the first one is that, uh, for the eFrodo, so we once actually aligned with the authors of the CFRG Frodo draft. So basically eFrodo is mainly for compatibility, because some applications already used the version of eFrodo. So in that case, I actually prefer maybe it's better to just include eFrodo as well in Valery's draft. That's one. Uh, second comment is that, um, I'm not sure whether you also including the version for 512 here, because 512 variant is actually not included in the ISO standardization.
Valery Smyslov: But OIDs exist.
Guilin: Okay. Yeah. Okay. Thank you.
Meiling: Hello, can you hear me?
Valery Smyslov: Yes.
Meiling: Uh, hi Valery, I have a couple of questions. I see IPsec working group has recently adapted the FrodoKEM for key exchange. Um, but I don't see any discussion with regard to using that for certificates. So could you elaborate on the use case for that and... and what is the plan for that?
Valery Smyslov: I think that using FrodoKEM in IPsec is independent from using it in LAMPS, because in IPsec it is used only for ephemeral key exchange, we don't use certificates. So it's just orthogonal problems. So actually it's... this draft is only try to fill a gap because we have an existed OIDs and don't have a document that defines how FrodoKEM should be represented in certificates, if somebody needs it. But IPsec draft doesn't need FrodoKEM.
Meiling: Yeah, I was just wondering which protocols you plan to use it at this work.
Valery Smyslov: To be frank, I don't know. So this draft just... well, I don't know other applications, but perhaps, for example, KEM-based authentication can be... there is another draft for KEM-based authentication in IPsec working group, and this draft can use certificates for FrodoKEM if... KEM that is used for authentication is FrodoKEM.
Meiling: Yeah, because KEM-based authentication did not go well within TLS, so that was my underlying question. But thanks, thanks for the clarification.
Valery Smyslov: Perhaps, but TLS is not IKEv2, TLS is more rigid and people do not want to change it. I don't know, it is not yet adopted on IPsec working group too, but still there is some interest. Thanks.
Deirdre: If the FrodoKEM document in CFRG were a little further along, um, I would be cool with this. I actually have some suggestions that I want to provide to the FrodoKEM spec in CFRG, um, that would need to be reflected in this document because it would be encoding keys and formats and things like that. So, kind of whatever Russ said.
Valery Smyslov: So, so you can... you can... you can make some effort for this document to process in CFRG.
Daniel Van Geest: Daniel Van Geest. So to answer Tero's question, it looks like the next presentation is going to be FrodoKEM in CMS, so there's a use case for you.
Valery Smyslov: Yes.
Russ Housley: Okay, it looks like the queue is empty. Thank you. I think we're going to put this a little bit on hold until we can see a document come out of the CFRG. Uh, I suspect we're going to end up in the same spot with this next one, but let's... Meiling, are you ready?
Meiling: Okay. Uh, this is also FrodoKEM in the cryptographic message syntax, the same background uh, with Valery's draft. So I... I also add a page here is for the background and the motivation here. So I... it's have some overlap, so I have go very simple for that. The goal of this draft is to define a clear specification for using eight variants FrodoKEM, um, in... as Valery said, eFrodo maybe not necessary, so I will keep same with... uh, with the variants in certificate. And second is to leverage the KEM reception infrastructure from RFC 9629 for seamless integration into the existing CMS framework. So the core mechanism is to use the, uh, KEM reception infrastructure here. We are have the conventions for FrodoKEM here. So, um, one of the eight FrodoKEM OIDs has already defined, and also we define the KDF here, and they must support this id-alg-HKDF-with-SHA-256. And also we use the wrap algorithm here, they must support for FrodoKEM-976 for the security of 128 bits and also support for KEM-1344 for the security of 256. So that's the, uh, security strength alignment here. Um, this... this more details about the eight FrodoKEM variants covered in my draft. Okay, and the OIDs is already defined. So, um, we have to see that the... we are two very similar draft with, uh, Valery's LAMPS, and we also have some... some content borrowed from the other CMS draft already in the working group. So, uh, this a very simple summary here. Uh, is this draft try to provide a solution, uh, offers a clear specification for the using of FrodoKEM in CMS and reuse the existing framework build up on, uh, build up on the RFC 9629 and defines the clear parameters in the KDF and, uh, key wrap algorithms for the interoperability, and also the, uh, we established the identifiers for the eight specific FrodoKEM variants. Um, and... but now I'm not sure, uh, in LAMPS, uh, it is viable for this work to go on, and we need, uh, us to feedback to make this draft go on or not. Thank you, and question.
Victor: Uh, I have one. Uh, standard objection to strict alignment. If you're going to support both AES variants, they should be supported for both of the KEM sizes, regardless of, uh, which combination, you know, the user picks. If you want AES-256, it should be the only one. If you want both AES-192 and 256, it should be usable with all the KEM sizes.
Meiling: Yeah, we want to use both.
Victor: Uh, so don't... drop the alignment requirements is my recommendation.
Meiling: Okay.
Scott Fluhrer: Okay, Scott Fluhrer, Cisco Systems. Uh, I repeat what I said over to Valery. Uh, there is no real reason to support eFrodo. Uh, again, it is asking for people to basically, if they misuse it and sign and use it too much, it becomes a security weakness, and there is no meaningful security... performance difference, so there is no real reason to support it at all. Thank you very much.
Meiling: Okay, got the idea. Just...
Richard: Uh, as long as we're repeating the discussion of the previous thing, can Russ you please mention the charter issue again?
Russ Housley: Okay. Sure. We... we can only do work on documents that are standardized by NIST or vetted by the CFRG. So this would be blocked until the CFRG publishes their document.
Meiling: Um, got it.
Russ Housley: All right, thank you. Uh, I suggest that Meiling and Valery, well, Valery's, but and Guilin, um, they may want to go volunteer to help finish off the CFRG document.
Meiling: Got it.
Russ Housley: All right. Well, we are out of time, and we're also out of agenda. So thank you very much, and enjoy the rest of your day.