Session Date/Time: 01 Jun 2026 13:00
Joe Mandel: Mark, how long do you want to wait? You think we should just get started since we have a handful of people already here?
Marc Blanchet: Uh, well, speaking from myself, I usually start just by, by the time. I'm just, okay, not, not waiting for people, you know, they just need to, you know, connect in advance and whatever. Your, your call.
Joe Mandel: We'll just get started then.
Marc Blanchet: Okay.
Joe Mandel: All right. Here's the Note Well, covers the IETF's processes and policies on conduct, your rights for IPR, and working group guidelines and procedures. Here's some meeting tips. Use a headset if you can. When you do enter the queue, state your name so we know who's speaking. And make sure your audio and videos are turned off unless you're presenting. Here is the notepad for today. If somebody can take notes, that would be great. And then here is the meeting link. Our agenda for today, we're covering the Note Well right now. And then we're going to pass it over to Debra to present her updates. All right. If there's no questions, we'll hand it off to Debra.
Debra Petta: Okay. Great. Thanks, Joe.
Joe Mandel: You're welcome.
Debra Petta: And here are your slides. Great. Thank you. And and will you um do those slides for me when I say next slide?
Joe Mandel: Yes, I can do that for you.
Debra Petta: Great. Thanks.
Joe Mandel: You're welcome.
Debra Petta: Okay. Uh, good morning or afternoon, everyone. Thank you for joining today's session. Today, I'll be walking you through the changes between version 0 and version 1 of the newly adopted draft ietf-ediint-rfc4130bis. This update addresses the technical review of the approved baseline version of this document to version 01, as well as incorporating important discussion points that came out of the previous working group session and discussions within the mailing list, particularly around HTTP connection management. This is a more focused presentation than what we did for the initial draft review. We're going to concentrate on what actually changed between these two versions and more importantly what the implementation impact looks like for those of you maintaining AS2 implementations. Additionally, we can focus on what is still missing and what still needs to be changed. Let's jump right in. Next slide, please. Version 1 represents our response to the technical review of the baseline document, as well as outcomes from working group discussion, particularly around too much complexity related to the listing of the algorithm capability permutations and HTTP connection management. Before we dive into the details, I want to point out the link at the top of the slide. This takes you to the IETF author tools diff viewer, which shows every single line that changed between version 0 and version 1. For those of you who want to do a deep technical review, that's your best resource. What I'm presenting today is a selected summary of the most significant changes. The changes have been divided into three major areas. First, the technical review. This encompasses the detailed technical review. Several important improvements have been made here. We've simplified how we specify algorithm requirements, clarified MIME type requirements, added guidance on algorithm lifecycle management. We've updated our TLS requirements to acknowledge TLS 1.3 as the current standard, and we've added AS2 product header specifications. Second, HTTP connection management. This came out of working group discussion and represents an important clarification. We've added explicit guidance about HTTP 1.1 persistent connections, clarified that connection close header is not required, and removed it from all our message examples in Appendix A. This aligns with modern HTTP 1.1 practice and improves performance. Third is compression and signature ordering. We've documented the implementation flexibility around where signatures can be placed relative to compression, while maintaining clear requirements for what receivers must support. Let's look at each of these areas in detail. Next slide, please. The technical review and comments provided on the mailing list led to several significant improvements in how we specify requirements. Starting with algorithm requirements simplified. In version 0, we enumerated 24 different permutations of algorithms with the intention of being comprehensive. It was noted that this was too complicated and potentially confusing. In version 1, we've replaced that with a concise capability summary that's much clearer about what implementations must support versus what they may support. This is editorial in nature. We didn't change the actual requirements, just how we expressed them. Next is MIME type requirements clarified. We distinguished between protocol level requirements, things that AS2 as a protocol mandates versus content specific requirements that depend on what kind of business data you're exchanging. This distinction wasn't clear in version 0 and led to some confusion about what implementations are actually required to support. Next is algorithm lifecycle management. This is new guidance that points to IANA registries for tracking algorithm deprecation. As algorithms get deprecated over time, as we've seen with MD5, SHA-1, and Triple DES, implementers need a clear reference point. We now point to the relevant IANA registries where these deprecation timelines are mandated or are maintained. Sorry. TLS requirements updated. This is an important change. We've acknowledged that TLS 1.3 specified in RFC 8446 is now the current standard. Implementations must support TLS 1.3 and may support TLS 1.2 for backward compatibility with legacy partners, but TLS 1.3 is the baseline. Additionally, we've changed HTTPS from recommended to required. This reflects current security best practices. AS2 implementations should be using HTTPS as the default transport. AS2 product header enhancement. We've added support for an optional private enterprise number prefix in the AS2 product header. This allows vendors to more clearly identify their products in a standardized way while maintaining backward compatibility with existing AS2 product values. Next slide, please. So one significant administrative improvement in version 1 is the creation of two new IANA registries. The first—
Marc Blanchet: Debra, are you using are you taking questions at the end or every slide or—
Debra Petta: Whatever you guys want to do. If you want want to take questions, we can do that or we can wait till the end. You tell me.
Marc Blanchet: Joe, any preference or—
Asger Smidt: Personally, I would rather take them as we go.
Debra Petta: Okay. Then let's do that.
Asger Smidt: That's fine.
Marc Blanchet: All right. Then then do we want to go back to the third slide? Or is that where the questions were?
Marc Blanchet: Yes, yes. I have a question on the third slide.
Joe Mandel: Okay. I'll go back.
Debra Petta: Okay. Thank you.
Marc Blanchet: Uh, well, two comments. One is, I, I think the TLS 1.2 um, will be, I think, a problem in the ISG, but I think we could defer that discussion at the end of your presentation for the document structure. Um, I think from the IETF parlance, uh, the way we do, instead of recommended or required, we say "must". So, you know, make sure that you're using uh, the RFC 2119, uh, wording, you know, which is typically, you know, an implementation "must" do things or that, so.
Debra Petta: "Must" or "may", right?
Marc Blanchet: Okay. In some ways it, you know, you know, any implementer, uh, uh, lazy way to do things is to just, you know, search "must" in an RFC and implement that, so.
Debra Petta: Are you talking about are you talking about the HTTPS?
Marc Blanchet: Yes, yes.
Debra Petta: Okay. So that's a "must" instead of—
Marc Blanchet: Of required.
Debra Petta: Okay.
Marc Blanchet: Typically, you would do that, you know, everywhere in the, in the document.
Russ Housley: Mark, the term required and shall are both in RFC 2119 as—
Marc Blanchet: Yeah, I know. I know. But, you know, usually "must" is the way you, you write your sentence. If it has a "must" then it's easier for people, so.
Debra Petta: Okay, that's noted. Anything else, um, anybody else have any questions? Okay. Can we move on? Next slide, please. All right.
Joe Mandel: We are on slide 4, correct?
Debra Petta: Yeah. I think that's where I kind of lost my I lost my flow a little bit. So, um, all right. Back to here. Um, so we're on the IANA. One significant administrative improvement in version 1 is the creation of two new IANA registries. The first is the AS2 HTTP Headers registry. This registry tracks all AS2 specific HTTP headers. You can see the five headers listed here: AS2-Version, AS2-From, AS2-To, AS2-Product, and EDIINT-Features. Having these in a formal IANA registry means there's now a central authoritative list. If AS2 specific headers are proposed in the future, they'll go through the proper IANA registration process. This brings AS2 in line with how other HTTP based protocols manage their header namespaces. The second registry is the AS2 Disposition Modifier Extensions registry. This documents the disposition modifier extensions that can appear in MDN messages. These are the machine readable codes that explain why message processing succeeded or failed. Um, you can see here, um, examples: unsupported format, unsupported MIC algorithm, decompression failed, and so on. Um, I want to call your attention to one specific note. We've documented that unknown trading relationship and unknown trading partner are used synonymously in practice. Both appear in existing implementations. The registry now officially recognizes both terms as valid, which resolves a source of confusion users have experienced in the field. These registries don't require any implementation changes. This is administrative infrastructure that makes AS2 easier to maintain and extend going forward. Question. Asger.
Asger Smidt: Yeah. Asger Smidt. Um, I mean, you, you kind of, uh, answered it there at the end, but it— If the IANA registry is the official list of like the modifier extensions that need to be supported, is it not possible to write a compliant implementation according to the spec, and then have that implementation become non-compliant without any changes to the spec, if new entries are added to the IANA registry? How could they be added to the IANA registry if they're not in the spec?
Debra Petta: Okay. So those things always go together. That's just That's basically what I wanted to know. Yeah, I would think so. That that we we put them in the specification, but then they're also in the IANA registry.
Asger Smidt: Okay. Fine. As, as long as they cannot be added to the registry without the spec being updated.
Debra Petta: That would be my my thought on it. But, um, I guess we see what everybody else thinks as well.
Asger Smidt: Okay. Good.
Debra Petta: Okay. Thanks. Um, Mark, did you have a a question?
Marc Blanchet: Oh, uh, yeah, actually. Um, so, um, Well, I was trying to verify exactly what you wrote in terms of uh, registration policy, but uh, okay. Um, so, uh, the, the document specification, the RFC, when it becomes an RFC, published RFC, doesn't change. It's, it's fixed. It's, it's over. You cannot make any change to it. The, one of the purposes of IANA, when we discuss, uh, last time about the IANA registry is, over time, people, uh, in the industry and implementation, have been using additional, um, uh, keywords. So, um, that means there's a difference in time about, you know, the actual use. So, the good part of having an IANA registry is that you keep those additional, you know, keywords or tokens or whatever strings being, uh, clearly identified in, you know, in a registry. Um, and then the question about conformance is, is, or, or certification is a different discussion. Um, so, that way you, you make sure, as we have discussed last time, that, um, not everybody is, is kind of, uh, using his own uh, string and, and then we have chaos, right? Uh, and the key point here is to avoid people registering all kind of strings is you have a registration policy that is somewhat restrictive. And there's a different, uh, variations of those, and we probably need to discuss them, um, where you can, you know, really, uh, ask people, uh, you know, for example, with what we call designated experts, which are people identified to review any additions to the registry. So that, you know, it's not, you know, unrelated, and makes sense and things like that. Or we can request a specification, which is a document somewhere, or we can request an Internet-Draft or RFC or whatever. So that is, uh, something that the working group should be discussed is, what is the level of, you know, requirements to add an entry in the registry. But, you know, back to the question, the previous comment, the conformance or the certification is a different topic. Uh, it's just, you know, not orthogonal, but uh, different. It— The fact that there is an entry in the registry doesn't mean you have to implement it. It's, it's just not that, right?
Debra Petta: Okay. Um, so then going back to the question that Asger had. Um, is, is that true then? Are we saying that, I guess I'm trying to repeat what you just said so that I'm understanding. Uh, we we're going to close the spec. There will be entries to the registry, but that doesn't mean that the implementations will become non-compliant or non-conforming or um, that there'll be interoperability issues if new ones are added.
Marc Blanchet: Well, you know, for, right. So, in your certification list, you could, uh, you know, criteria, you could list the, the ones that you want to make sure that they are supported by the implementation. But that's, that's your certification profile, right? That's not— But not everybody goes through Drummond certification. That's what we're trying to to cover. We're trying to cast a wider net here and and say that even if you don't do Drummond certification, you're still going to be, if you pick up this spec, you're going to be able to become interoperable, right. Right. For, yeah. For example, you, you know, think about basic HTTP. You can have, I don't know how many, I don't know, maybe 50 or or MIME types. There's probably 2,000 MIME types, but not everybody implement them, right? So.
Debra Petta: Okay. All right. I get it.
Russ Housley: So, Debra, this is Russ. If you want the highest bar, then the this document sets the rules for changes to the IANA registry. That policy could be you need to update the IETF RFC. And if that's the case, you will get what you said, which is only updates to the RFC will make changes to the uh, IANA registry. If you find that you want to be more flexible to accommodate uh, easier additions to the registry, then you might have first-come, first-served. And there's everything in between.
Debra Petta: Okay. Um, so I guess we we want to make a decision then as a group how we want how flexible we want to be.
Marc Blanchet: Exactly.
Debra Petta: Okay. All right. Very good. Thanks. Next, Erik.
Erik Wramner: Uh, yes. Uh, I just want to note that, uh, at least the disposition modifier extensions are usually not acted upon by the AS2 product. It, uh, sets them to indicate what was wrong, and then the other side, which is also an AS2 server, reads the code and and can, uh, suggests, uh, what to do for for a user. But if, uh, if the calling AS2 gets back a code that it doesn't understand, it shouldn't go haywire, and and this will happen. So, all, all products must support unknown codes. It, it's just that the support for the end user will be slightly less, uh, stellar. So, I don't think it's a great problem if, uh, if, uh, additional codes are added to the registry, even if all products are not supporting them.
Debra Petta: Okay. Thank you. Mark, do you have another comment, Mark? No?
Marc Blanchet: No, I'm done.
Debra Petta: Okay. All right. Can we move on to the next page? Very good. Thank you. All right. So, this slide illustrates one of the most significant clarifications in version 1, and it came directly from the working group discussions. Looking at the the left column, version 0, you can see what the situation was. We provided no explicit guidance on HTTP 1.1 persistent connections. The connection close header appeared in our message examples in Appendix A. This implied, though we never explicitly stated it, that connections should be closed after each message. We didn't discuss the performance impl— implications of this approach. Now look at the right column, version 1. We've added a new subsection that explicitly explains how HTTP 1.1 persistent connections work in the AS2 context. We've clarified that connection close is not required. It's perfectly valid for implementations to keep connections open and reuse them for multiple AS2 messages. We've removed connection close from all AS2 message examples in Appendix A. And we've documented the performance benefits of connection reuse. However, connections may still be closed if needed by implementations. This is not a must, it is a may. Um, here's the key point. HTTP 1.1 persistent connections are the default behavior. When you close a connection after every message, you're forcing a new TCP connection, a new TLS handshake, and potentially triggering connection throttling on the receiving side. For high volume trading partner partners exchanging hundreds or thousands of messages per day, this overhead is significant. The impact statement at the bottom summarizes this. We now have better alignment with modern HTTP 1.1 implementations and the path to improved performance. Implementations that want to leverage persistent connections now have clear specification support for doing so. Next slide, please. Oh. Well, this doesn't fit real well, but okay. Um, compression and signature ordering has been a source of confusion in AS2 implementations, so we took the opportunity in version 1 to provide clear guidance. Starting with point 1, compression always before encryption. This is unchanged from RFC 4130 and version 0. Um, compression must always occur before encryption. You want to compress data when it's still in plaintext format. Trying to compress encry— trying to compress encrypted data is pointless because encryption destroys the patterns that compression algorithms rely on. This requirement is firm and non-negotiable. Point 2, flexibility with signature place— placement. Here's where we documented existing practice. There are two valid orderings, and both appear in production systems. You can compress then sign, where the compressed data is inside the signature envelope, or you can sign then compress, where the signature is inside the compression envelope. Both orderings are valid in AS2. The reason both exist are historical. Different implementations made different choices early on, and both approaches have been successfully deployed. Point 3, receiver requirements. This is the critical requirement. Implementations must support decompressing both orderings. You can't assume that your trading partners will all use the same ordering, um, that you prefer. If you only handle one ordering, you'll have interoperability failures. This is a firm must requirement. Um, point 4 is MIC computation. We've clarified that message integrity check computation includes the inner MIME headers, not just body content. This is critical for proper message integrity validation. The message integrity check is the hash value that gets reported back in the MDN. If senders and receivers disagree about what gets included in the MIC calculation, the MDN will report a mismatch and you'll get a failed message exchange. Getting this right is essential for non-repudiation of receipt. The practical takeaway is that if you're implementing compression support, make sure your code can handle both orderings on receive, even if you only generate one ordering on send. Next slide, please. Editorial changes in references. Version 1 includes several editorial improvements that enhance the quality and clarity of the specification. Starting with updated normative references. We've added three RFCs to the normative reference section. RFC 5246 is TLS 1.2, RFC 8446 is TLS 1.3, and RFC 9110 is the current HTTP semantic specification. This is the modern replacement for the older RFC 2616 that we previously were referencing. Um, these reference updates bring the specification in line with current IETF standards. Terminology updates. We made two systematic terminology changes throughout the document. First, we replaced TCP/IP connection with HTTP connection throughout. This is more accurate because we're specifying HTTP level behavior, not TCP level behavior. Second, we removed the dated Internet EDI terminology and consistently use EDI/EC instead. Internet EDI made sense in 2005 when distinguishing Internet based EDI from VAN based EDI, but today it's just confusing. Fixed technical issues. We corrected typos and formatting issues that were identified during the document review. We resolved some internal xml2rfc anchor resolution problems that were causing broken internal links in the generated HTML and text versions, and we fixed hardcoded section references to use proper anchors. Change log's been updated. We've added complete documentation in version 1 of the version 1 changes to the change log section. This helps readers understand the evolution of the specification and provides a clear audit trail. None of these editorial changes affect the technical requirements. These are quality of life improvements that make the specification easier to read, maintain, and to implement from. Next slide, please. Oh, this is the um, this, this is probably the most important slide for implementers. Let me walk through what actually requires work versus what's just documentation improvements. Looking at the left column, changes requiring implementation updates: Compression signature ordering. If you support compression, you must verify that your implementation can decompress both orderings on receive: compress then sign, and sign then compress. Many implementations already do this, but if you haven't tested it, now is the time. MIC computation. Verify that your MIC calculations include the inner MIME headers. This should already be the case in most implementations, but it's worth confirming. If you're getting MIC mismatches with certain trading partners, this could be why. HTTP connection management. If you want to leverage persistent connections for improved performance, you can do so now with clear specification support. This is optional. If your implementation closes connections after each message, that's still valid in AS2, but if you're handling high volume trading relationships, implementing persistent connection support can significantly improve throughput. AS2 product header. This is noted to be optional in versions 1.2 and back, but is required in version 1.3 and on. Version 1 of the spec includes the ability to optionally provide a private enterprise number registry prefix in your AS2 product header. If you choose to do so, you'll need to add support for that format. This prefix is a nice to have, not a must have. Changes requiring no action on the right side: Algorithms simplification. This is editorial clarity only. We didn't change what algorithms you need to support, just how we document them. IANA registries. These are administrative. These registries don't impose new requirements. They're just organizing existing requirements in a more maintainable way. TLS 1.3 acknowledgment. If you're using modern TLS library, you already support TLS 1.3. This is recognizing reality, not adding new requirements. Terminology updates. We just changed how we describe things, not what things are required. The summary at the bottom captures our philosophy. Overall, this is minimal implementation impact. Most of the changes are clarifications rather than new requirements. The main action items are around compression ordering support and considering persistent HTTP connections for performance improvement. Next slide, please. Okay. I don't know if it's all going to fit, but okay. So, this slide addresses a fundamental document structure question that was raised during the technical review of the draft, a question that goes beyond the inline comments we addressed in version 1 and requires working group discussion and consensus. Let me frame the issue. The core issue is this. Our current specification attempts to define both modern security requirements, that is SHA-256, AES, TLS 1.3, and backward compatibility with legacy algorithms, meaning SHA-1, Triple DES, and TLS 1.2, in the same normative sections. But it's been noted that this creates ambiguity. The specification effectively says both: Triple DES is okay, and Triple DES is not okay, depending on which sections you're reading. This makes it difficult to understand what conformance actually means. This isn't just an editorial problem. It's a decision that affects how we structure the entire document and what AS2 version 1.3 actually means going forward. We have three possible approaches and I want to walk through each one. Option A: Clean version 1.3 with a legacy appendix. This is shown in blue. Um, with this approach, the normative section would contain only modern requirements. SHA-256 would be a must, Triple DES would be explicitly forbidden in normative text. All the legacy interoperability guidance that is accepting SHA-1 and Triple DES from legacy partners but not generating them would move to a non-normative appendix. The pros of this approach are: it's a clean specification that's likely to pass IESG security review without pushback. The cons: it may break existing RFC 4130 implementations that only support legacy algorithms. Those implementations would no longer be conformant to the updated specification. Option B: Mandatory legacy support. This is shown in green. This is essentially our current approach. The normative sections include both modern and legacy algorithms. SHA-256 is a must, but SHA-1 is a may with a deprecation warning. Triple DES is a may, but is also deprecated. The current section 1.2.1 provides legacy guidance normatively. The pros: this provides true backward compatibility and existing implementations will remain conformant. The cons: this may face pushback in the IESG security review because we're normatively blessing deprecated algorithms. And it creates what has been referred to as two tier conformance. That is, implementations that are technically conformant but don't follow modern security practices. Option C: Two document approach. This is shown in yellow. With this approach, we would publish two separate documents. Document 1 would be RFC 4130bis, a minimal update to RFC 4130 containing only essential corrections and clarifications, keeping the legacy algorithm support. Document 2 would be AS2 version 2.0, a completely clean modern protocol with a new version number and no legacy baggage. The pros: this is the cleanest separation. You serve distinct audiences with documents tailored to their needs. The cons: it's more work, it takes longer, and AS2 version 2.0 may face adoption challenges in an environment where existing AS2 version 1.x deployments are deeply ingrained. Um, now we've already had some discussion about this on the mailing list and I want to summarize the two perspectives. The first is that backward compatibility with SHA-1 and Triple DES is definitional to AS2 version 1.3. It's part of what version 1.3 means. If you remove that backward compatibility, you're no longer writing a specification for AS2 version 1.3. You're creating AS2 version 1.4 or version 2.0, which is essentially a different protocol. This position is that Option B, keeping legacy support normatively, is the correct approach for something called AS2 version 1.3. The other perspective asserts that the new RFC should cover a modernized specification without ambiguity. You can have a non-normative section that describes how version 1.3 implementations interoperate with older versions when there's a backward compatibility issue. But the normative requirements should be clean and modern. If that means calling it version 1.4 or version 2.0 to address the definitional concern of the first perspective, then Option A might be preferred to Option B, provided we accept the version number change. The key question in red at the bottom is what we need from the working group. Which approach should we pursue? This is a fundamental design decision that affects not just version 1 or version 2, but the entire structure of all future revisions. We will need rough consensus on this before we can finalize the document. Let me be clear about what's at stake. If we choose Option A or Option B— Option C, sorry, we're effectively saying that the updated specification is targeted at new implementations and modernization of existing implementations, and legacy only deployments may need to stay on RFC 4130. If we choose Option B, we're saying that AS2 version 1.3 means a protocol that bridges the legacy and modern perspectives, and implementations can choose their position on that spectrum. I don't have an answer for which approach is right. That's a working group decision. What I can tell you is that we need to make this decision explicitly rather than leaving it ambiguous, which is what version 1 currently does. So, I'm opening up this for discussion. What's your perspective? What approach makes sense for the AS2 landscape? What approach serves implementers and the user community best? And I will open the floor to Asger.
Asger Smidt: Uh, yes. Since I've been one of the most vocal proponents of backward compatibility, I thought I might as well go first, particularly since I've kind of adjusted my stance. I think we are not in the group as far from each other as it seems. I think we just have different presumptions, so to speak. My, my perspective is sort of a combination between Option A and C, really, now. Um, my concern was always we have to let systems communicate with older systems, but we also have to allow those systems to actually conform to the 1.3 spec. And as phrased, that did not seem to be possible without having explicit backward compatibility in 1.3. But the way I see it is, as long as we make it explicit in the 1.3 spec that systems are allowed to support 1.2 for communication with 1.2 systems, then the 1.3 actual specification should actually be clean and just contain the 1.3 things, as long as we make it clear that it's okay for a system to be able to do both, as long as it only does 1.3 stuff when it's operating in 1.3 mode, so to speak. Both outgoing and incoming.
Debra Petta: Okay. Thank you. Um, next, Bojidar.
Bojidar Ivanov: Yes. Asger, I'm happy to hear what you just said. I've been a strong proponent to high security standards, so if we touch the RFC, doesn't matter whether it's Bis or its 2.0, it's a change. And with this change, we conform to only modern algorithms, and being pragmatic, of course, any implementation will need to talk to old versions. So, even if you say you are version 1.3 compliant, you will implement you will implement compatibility with broken algorithms if if that's required for your business. So, I'm I'm actually more towards Option A, keeping it version 3 or version 4, doesn't matter that much. Um, exclude broken algorithms from the specification, and have a non-normative section where we explicitly say, "Yes, it's allowed to communicate with older systems and implement older versions of the RFC."
Debra Petta: Okay. Thank you. Erik.
Erik Wramner: Yes, hi, Erik. Um, I kind of agree, uh, but unless we go for Option B, where we have mandatory legacy support, I think it's very important in the normative text, that we document how to select when it's okay to use the old protocols and when it's okay or required to use the new protocols. In other words, the, the way to select if the other system is a legacy system or not must be documented. And, and it can say that this, this is handled by the product with its user interface or configuration options or, or whatever. But it must be documented and clear so that two different products, uh, both know how to kind of enable the legacy support and go AS2 1.2 instead of AS2 1.3.
Debra Petta: Okay. All right. So, we it seems like we we've both Option A or Option B. Or is it Option A with saying that um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So for example, if if you are sending the first message and uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you. Russ.
Russ Housley: Um, this, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as may in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought. I still think, though, we want to open that to the um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from from the larger community before we start changing the specification. Um, Russ.
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, you read my my mind, Russ of it. Um, yeah, uh, I'm Okay, I have two comments. One is, uh, we really want to make sure that we are uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus. Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update um, 4130 with the new new security, right? Um, even if that breaks backward compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or ISG evaluation, it's not going to you're not going to pass it. I, as responsible AD, also would not even last call it. So, um, the, the, so I think we have a problem there, and I don't know what the I don't know I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that that is needed by the clients to say, "If I want to do 4130, I do I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way the way a lot of people solve this problem. So, uh, maybe maybe it's just mine my I don't understand how why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think uh, discovery mechanism was what we were discussing right now, right? So there there needs to be a normative documented way to say when the AS2 product is supposed to use the new version with the new algorithms, and when it is okay for it to fall back to the old version to support old products that we know are out there, and that we know will not be replaced for a long time.
Russ Housley: So is that is that it? Is there so you you're not going to say, uh, you're not going to get a document that's going to say, "Oh, it's okay to start using SHA-1," right? That's just not not a thing, because it's not okay, uh, in the modern on the modern Internet, you should be using, uh, modern cryptography. The, the, what we need here is a transition mechanism that says, for for clients that need to use the 4130bis, uh, they can discover what the endpoint is or however you however you do that communication and then they start doing that. And that's all we need to describe. We don't need to describe what's in RFC 4130 as being okay, right? There are there are old clients out there that are going to continue doing that. We don't need to say, "That's okay to continue doing that," they are just going to continue doing it. There's no there's no need to describe it. The only only thing you need to describe is what that transition mechanism is.
Marc Blanchet: Go ahead, Asger.
Asger Smidt: Yeah. Agreed. I don't think we should refer to any of the old technologies specifically. We should just refer to 4130. Saying, for communication with legacy systems, use the 4130 spec. And for modern systems, use this.
Debra Petta: Okay. Mark, go ahead.
Marc Blanchet: Um, yeah, continuing on the transition mechanism, uh, we had some discussion about that, uh, last time, but I'm not sure we had we had gone through, uh, you know, more about this. But, um, one way actually the uh, community, which is which has been using AS2 and is kind of uh, going out of it, moving out of it, is the GDSN GS1 GDSN GDSN and their new way of doing is pure REST. But the discovery part is actually using an— I was trying to find the the reference. There's a, um, uh, JSON, uh, file that you could put in in on your website that describes and then you define the schema for it and that, that could be the way you would, uh, discover what the other endpoint is supporting, uh, and, you know, if, by the end of this meeting maybe I I will find the, the RFC number, but that might be one way of doing.
Debra Petta: Okay. Go ahead, Erik.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? All right. Should we move on to the next slide or does anybody else want any have anything else to say? Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're this is kind of the wrap up slide. Okay. So where do we go from here? Um, first, we're we're um the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list. Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward. Now I'd um like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or should we move on? Mark, do you you have something else?
Marc Blanchet: Yeah. Um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a there's only 11 people including the chairs and myself on this um, in this call, that we should open up this this whole to to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a a comment for more for more feedback from the entire working group community. So that we can make sure that everybody is aware um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we we're sure that everybody's on the same page.
Marc Blanchet: Right. Uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my and and correct me if I'm wrong, um, either Asger or, um, Erik, um, what what I think we're we're saying is that we want to include a normative section that just says what to do if a message is received that is is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130, but then if that's not true, then I think we're going to keep 4130 and make this a new spec for for going forward, which would I think be Option A, have two— two specs, or a clean clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of a an option A.1 or something like that. It's not Or is it a two document approach? I don't know which which one it is specifically. You guys talk. I'm I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we it seems like we we've both Option A or Option B. Or is it Option A with saying that um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So for example, if if you are sending the first message and uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you. Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as may in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought. I still think, though, we want to open that to the um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from from the larger community before we start changing the specification. Um, Russ.
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, you read my my mind, Russ of it. Um, yeah, uh, I'm Okay, I have two comments. One is, uh, we really want to make sure that we are uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus. Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update um, 4130 with the new new security, right? Um, even if that breaks backward compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or ISG evaluation, it's not going to you're not going to pass it. I, as responsible AD, also would not even last call it. So, um, the, the, so I think we have a problem there, and I don't know what the I don't know I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that that is needed by the clients to say, "If I want to do 4130, I do I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way the way a lot of people solve this problem. So, uh, maybe maybe it's just mine my I don't understand how why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any have anything else to say? Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're this is kind of the wrap up slide. Okay. So where do we go from here? Um, first, we're we're um the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list. Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward. Now I'd um like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or should we move on? Mark, do you you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a there's only 11 people including the chairs and myself on this um, in this call, that we should open up this this whole to to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a a comment for more for more feedback from the entire working group community. So that we can make sure that everybody is aware um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my and and correct me if I'm wrong, um, either Asger or, um, Erik, um, what what I think we're we're saying is that we want to include a normative section that just says what to do if a message is received that is is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130, but then if that's not true, then I think we're going to keep 4130 and make this a new spec for for going forward, which would I think be Option A, have two— two specs, or a clean clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of a an option A.1 or something like that. It's not Or is it a two document approach? I don't know which which one it is specifically. You guys talk. I'm I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we it seems like we we've both Option A or Option B. Or is it Option A with saying that um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So for example, if if you are sending the first message and uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you. Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as may in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought. I still think, though, we want to open that to the um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from from the larger community before we start changing the specification. Um, Russ.
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, you read my my mind, Russ of it. Um, yeah, uh, I'm Okay, I have two comments. One is, uh, we really want to make sure that we are uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus. Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update um, 4130 with the new new security, right? Um, even if that breaks backward compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or ISG evaluation, it's not going to you're not going to pass it. I, as responsible AD, also would not even last call it. So, um, the, the, so I think we have a problem there, and I don't know what the I don't know I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that that is needed by the clients to say, "If I want to do 4130, I do I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way the way a lot of people solve this problem. So, uh, maybe maybe it's just mine my I don't understand how why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any have anything else to say? Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're this is kind of the wrap up slide. Okay. So where do we go from here? Um, first, we're we're um the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list. Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward. Now I'd um like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or should we move on? Mark, do you you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a there's only 11 people including the chairs and myself on this um, in this call, that we should open up this this whole to to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a a comment for more for more feedback from the entire working group community. So that we can make sure that everybody is aware um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my and and correct me if I'm wrong, um, either Asger or, um, Erik, um, what what I think we're we're saying is that we want to include a normative section that just says what to do if a message is received that is is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130, but then if that's not true, then I think we're going to keep 4130 and make this a new spec for for going forward, which would I think be Option A, have two— two specs, or a clean clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of a an option A.1 or something like that. It's not Or is it a two document approach? I don't know which which one it is specifically. You guys talk. I'm I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we it seems like we we've both Option A or Option B. Or is it Option A with saying that um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So for example, if if you are sending the first message and uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you. Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as may in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought. I still think, though, we want to open that to the um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from from the larger community before we start changing the specification. Um, Russ.
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, you read my my mind, Russ of it. Um, yeah, uh, I'm Okay, I have two comments. One is, uh, we really want to make sure that we are uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus. Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update um, 4130 with the new new security, right? Um, even if that breaks backward compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or ISG evaluation, it's not going to you're not going to pass it. I, as responsible AD, also would not even last call it. So, um, the, the, so I think we have a problem there, and I don't know what the I don't know I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that that is needed by the clients to say, "If I want to do 4130, I do I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way the way a lot of people solve this problem. So, uh, maybe maybe it's just mine my I don't understand how why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any have anything else to say? Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're this is kind of the wrap up slide. Okay. So where do we go from here? Um, first, we're we're um the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list. Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward. Now I'd um like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or should we move on? Mark, do you you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a there's only 11 people including the chairs and myself on this um, in this call, that we should open up this this whole to to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a a comment for more for more feedback from the entire working group community. So that we can make sure that everybody is aware um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my and and correct me if I'm wrong, um, either Asger or, um, Erik, um, what what I think we're we're saying is that we want to include a normative section that just says what to do if a message is received that is is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130, but then if that's not true, then I think we're going to keep 4130 and make this a new spec for for going forward, which would I think be Option A, have two— two specs, or a clean clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of a an option A.1 or something like that. It's not Or is it a two document approach? I don't know which which one it is specifically. You guys talk. I'm I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we it seems like we we've both Option A or Option B. Or is it Option A with saying that um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So for example, if if you are sending the first message and uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you. Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as may in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought. I still think, though, we want to open that to the um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from from the larger community before we start changing the specification. Um, Russ.
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, you read my my mind, Russ of it. Um, yeah, uh, I'm Okay, I have two comments. One is, uh, we really want to make sure that we are uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus. Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update um, 4130 with the new new security, right? Um, even if that breaks backward compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or ISG evaluation, it's not going to you're not going to pass it. I, as responsible AD, also would not even last call it. So, um, the, the, so I think we have a problem there, and I don't know what the I don't know I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that that is needed by the clients to say, "If I want to do 4130, I do I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way the way a lot of people solve this problem. So, uh, maybe maybe it's just mine my I don't understand how why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any have anything else to say? Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're this is kind of the wrap up slide. Okay. So where do we go from here? Um, first, we're we're um the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list. Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward. Now I'd um like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or should we move on? Mark, do you you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a there's only 11 people including the chairs and myself on this um, in this call, that we should open up this this whole to to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a a comment for more for more feedback from the entire working group community. So that we can make sure that everybody is aware um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my and and correct me if I'm wrong, um, either Asger or, um, Erik, um, what what I think we're we're saying is that we want to include a normative section that just says what to do if a message is received that is is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130, but then if that's not true, then I think we're going to keep 4130 and make this a new spec for for going forward, which would I think be Option A, have two— two specs, or a clean clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of a an option A.1 or something like that. It's not Or is it a two document approach? I don't know which which one it is specifically. You guys talk. I'm I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we it seems like we we've both Option A or Option B. Or is it Option A with saying that um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So for example, if if you are sending the first message and uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you. Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as may in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought. I still think, though, we want to open that to the um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from from the larger community before we start changing the specification. Um, Russ.
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, you read my my mind, Russ of it. Um, yeah, uh, I'm Okay, I have two comments. One is, uh, we really want to make sure that we are uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus. Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update um, 4130 with the new new security, right? Um, even if that breaks backward compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or ISG evaluation, it's not going to you're not going to pass it. I, as responsible AD, also would not even last call it. So, um, the, the, so I think we have a problem there, and I don't know what the I don't know I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that that is needed by the clients to say, "If I want to do 4130, I do I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way the way a lot of people solve this problem. So, uh, maybe maybe it's just mine my I don't understand how why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any have anything else to say? Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're this is kind of the wrap up slide. Okay. So where do we go from here? Um, first, we're we're um the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list. Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward. Now I'd um like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or should we move on? Mark, do you you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a there's only 11 people including the chairs and myself on this um, in this call, that we should open up this this whole to to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a a comment for more for more feedback from the entire working group community. So that we can make sure that everybody is aware um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my and and correct me if I'm wrong, um, either Asger or, um, Erik, um, what what I think we're we're saying is that we want to include a normative section that just says what to do if a message is received that is is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130, but then if that's not true, then I think we're going to keep 4130 and make this a new spec for for going forward, which would I think be Option A, have two— two specs, or a clean clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of a an option A.1 or something like that. It's not Or is it a two document approach? I don't know which which one it is specifically. You guys talk. I'm I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we it seems like we we've both Option A or Option B. Or is it Option A with saying that um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So for example, if if you are sending the first message and uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you. Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as may in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought. I still think, though, we want to open that to the um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from from the larger community before we start changing the specification. Um, Russ.
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, you read my my mind, Russ of it. Um, yeah, uh, I'm Okay, I have two comments. One is, uh, we really want to make sure that we are uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus. Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update um, 4130 with the new new security, right? Um, even if that breaks backward compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or ISG evaluation, it's not going to you're not going to pass it. I, as responsible AD, also would not even last call it. So, um, the, the, so I think we have a problem there, and I don't know what the I don't know I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that that is needed by the clients to say, "If I want to do 4130, I do I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way the way a lot of people solve this problem. So, uh, maybe maybe it's just mine my I don't understand how why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any have anything else to say? Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're this is kind of the wrap up slide. Okay. So where do we go from here? Um, first, we're we're um the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list. Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward. Now I'd um like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or should we move on? Mark, do you you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a there's only 11 people including the chairs and myself on this um, in this call, that we should open up this this whole to to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a a comment for more for more feedback from the entire working group community. So that we can make sure that everybody is aware um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my and and correct me if I'm wrong, um, either Asger or, um, Erik, um, what what I think we're we're saying is that we want to include a normative section that just says what to do if a message is received that is is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130, but then if that's not true, then I think we're going to keep 4130 and make this a new spec for for going forward, which would I think be Option A, have two— two specs, or a clean clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of a an option A.1 or something like that. It's not Or is it a two document approach? I don't know which which one it is specifically. Guys talk. I'm I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we it seems like we we've both Option A or Option B. Or is it Option A with saying that um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So for example, if if you are sending the first message and uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you. Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as may in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought. I still think, though, we want to open that to the um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from from the larger community before we start changing the specification. Um, Russ.
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, you read my my mind, Russ of it. Um, yeah, uh, I'm Okay, I have two comments. One is, uh, we really want to make sure that we are uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus. Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update um, 4130 with the new new security, right? Um, even if that breaks backward compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or ISG evaluation, it's not going to you're not going to pass it. I, as responsible AD, also would not even last call it. So, um, the, the, so I think we have a problem there, and I don't know what the I don't know I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that that is needed by the clients to say, "If I want to do 4130, I do I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way the way a lot of people solve this problem. So, uh, maybe maybe it's just mine my I don't understand how why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any have anything else to say? Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're this is kind of the wrap up slide. Okay. So where do we go from here? Um, first, we're we're um the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list. Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward. Now I'd um like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or should we move on? Mark, do you you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a there's only 11 people including the chairs and myself on this um, in this call, that we should open up this this whole to to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a a comment for more for more feedback from the entire working group community. So that we can make sure that everybody is aware um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my and and correct me if I'm wrong, um, either Asger or, um, Erik, um, what what I think we're we're saying is that we want to include a normative section that just says what to do if a message is received that is is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130, but then if that's not true, then I think we're going to keep 4130 and make this a new spec for for going forward, which would I think be Option A, have two— two specs, or a clean clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of a an option A.1 or something like that. It's not Or is it a two document approach? I don't know which which one it is specifically. Guys talk. I'm I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we it seems like we we've both Option A or Option B. Or is it Option A with saying that um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So for example, if if you are sending the first message and uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you. Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as may in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought. I still think, though, we want to open that to the um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from from the larger community before we start changing the specification. Um, Russ.
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, you read my my mind, Russ of it. Um, yeah, uh, I'm Okay, I have two comments. One is, uh, we really want to make sure that we are uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus. Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update um, 4130 with the new new security, right? Um, even if that breaks backward compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or ISG evaluation, it's not going to you're not going to pass it. I, as responsible AD, also would not even last call it. So, um, the, the, so I think we have a problem there, and I don't know what the I don't know I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that that is needed by the clients to say, "If I want to do 4130, I do I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way the way a lot of people solve this problem. So, uh, maybe maybe it's just mine my I don't understand how why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any have anything else to say? Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're this is kind of the wrap up slide. Okay. So where do we go from here? Um, first, we're we're um the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list. Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward. Now I'd um like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or should we move on? Mark, do you you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a there's only 11 people including the chairs and myself on this um, in this call, that we should open up this this whole to to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a a comment for more for more feedback from the entire working group community. So that we can make sure that everybody is aware um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my and and correct me if I'm wrong, um, either Asger or, um, Erik, um, what what I think we're we're saying is that we want to include a normative section that just says what to do if a message is received that is is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130, but then if that's not true, then I think we're going to keep 4130 and make this a new spec for for going forward, which would I think be Option A, have two— two specs, or a clean clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of a an option A.1 or something like that. It's not Or is it a two document approach? I don't know which which one it is specifically. Guys talk. I'm I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we it seems like we we've both Option A or Option B. Or is it Option A with saying that um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So for example, if if you are sending the first message and uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you. Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as may in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought. I still think, though, we want to open that to the um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from from the larger community before we start changing the specification. Um, Russ.
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, you read my my mind, Russ of it. Um, yeah, uh, I'm Okay, I have two comments. One is, uh, we really want to make sure that we are uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus. Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update um, 4130 with the new new security, right? Um, even if that breaks backward compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or ISG evaluation, it's not going to you're not going to pass it. I, as responsible AD, also would not even last call it. So, um, the, the, so I think we have a problem there, and I don't know what the I don't know I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that that is needed by the clients to say, "If I want to do 4130, I do I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way the way a lot of people solve this problem. So, uh, maybe maybe it's just mine my I don't understand how why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any have anything else to say? Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're this is kind of the wrap up slide. Okay. So where do we go from here? Um, first, we're we're um the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list. Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward. Now I'd um like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or should we move on? Mark, do you you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a there's only 11 people including the chairs and myself on this um, in this call, that we should open up this this whole to to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a a comment for more for more feedback from the entire working group community. So that we can make sure that everybody is aware um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my and and correct me if I'm wrong, um, either Asger or, um, Erik, um, what what I think we're we're saying is that we want to include a normative section that just says what to do if a message is received that is is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130, but then if that's not true, then I think we're going to keep 4130 and make this a new spec for for going forward, which would I think be Option A, have two— two specs, or a clean clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of a an option A.1 or something like that. It's not Or is it a two document approach? I don't know which which one it is specifically. Guys talk. I'm I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we it seems like we we've both Option A or Option B. Or is it Option A with saying that um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So for example, if if you are sending the first message and uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you. Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as may in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought. I still think, though, we want to open that to the um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from from the larger community before we start changing the specification. Um, Russ.
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, you read my my mind, Russ of it. Um, yeah, uh, I'm Okay, I have two comments. One is, uh, we really want to make sure that we are uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus. Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update um, 4130 with the new new security, right? Um, even if that breaks backward compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or ISG evaluation, it's not going to you're not going to pass it. I, as responsible AD, also would not even last call it. So, um, the, the, so I think we have a problem there, and I don't know what the I don't know I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that that is needed by the clients to say, "If I want to do 4130, I do I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way the way a lot of people solve this problem. So, uh, maybe maybe it's just mine my I don't understand how why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any have anything else to say? Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're this is kind of the wrap up slide. Okay. So where do we go from here? Um, first, we're we're um the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list. Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward. Now I'd um like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or should we move on? Mark, do you you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a there's only 11 people including the chairs and myself on this um, in this call, that we should open up this this whole to to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a a comment for more for more feedback from the entire working group community. So that we can make sure that everybody is aware um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my and and correct me if I'm wrong, um, either Asger or, um, Erik, um, what what I think we're we're saying is that we want to include a normative section that just says what to do if a message is received that is is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130, but then if that's not true, then I think we're going to keep 4130 and make this a new spec for for going forward, which would I think be Option A, have two— two specs, or a clean clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of a an option A.1 or something like that. It's not Or is it a two document approach? I don't know which which one it is specifically. Guys talk. I'm I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we it seems like we we've both Option A or Option B. Or is it Option A with saying that um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So for example, if if you are sending the first message and uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you. Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as may in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought. I still think, though, we want to open that to the um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from from the larger community before we start changing the specification. Um, Russ.
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, you read my my mind, Russ of it. Um, yeah, uh, I'm Okay, I have two comments. One is, uh, we really want to make sure that we are uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus. Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update um, 4130 with the new new security, right? Um, even if that breaks backward compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or ISG evaluation, it's not going to you're not going to pass it. I, as responsible AD, also would not even last call it. So, um, the, the, so I think we have a problem there, and I don't know what the I don't know I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that that is needed by the clients to say, "If I want to do 4130, I do I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way the way a lot of people solve this problem. So, uh, maybe maybe it's just mine my I don't understand how why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any have anything else to say? Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're this is kind of the wrap up slide. Okay. So where do we go from here? Um, first, we're we're um the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list. Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward. Now I'd um like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or should we move on? Mark, do you you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a there's only 11 people including the chairs and myself on this um, in this call, that we should open up this this whole to to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a a comment for more for more feedback from the entire working group community. So that we can make sure that everybody is aware um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my and and correct me if I'm wrong, um, either Asger or, um, Erik, um, what what I think we're we're saying is that we want to include a normative section that just says what to do if a message is received that is is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130, but then if that's not true, then I think we're going to keep 4130 and make this a new spec for for going forward, which would I think be Option A, have two— two specs, or a clean clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of a an option A.1 or something like that. It's not Or is it a two document approach? I don't know which which one it is specifically. Guys talk. I'm I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we it seems like we we've both Option A or Option B. Or is it Option A with saying that um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So for example, if if you are sending the first message and uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you. Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as may in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought. I still think, though, we want to open that to the um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from from the larger community before we start changing the specification. Um, Russ.
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, you read my my mind, Russ of it. Um, yeah, uh, I'm Okay, I have two comments. One is, uh, we really want to make sure that we are uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus. Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update um, 4130 with the new new security, right? Um, even if that breaks backward compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or ISG evaluation, it's not going to you're not going to pass it. I, as responsible AD, also would not even last call it. So, um, the, the, so I think we have a problem there, and I don't know what the I don't know I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that that is needed by the clients to say, "If I want to do 4130, I do I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way the way a lot of people solve this problem. So, uh, maybe maybe it's just mine my I don't understand how why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any have anything else to say? Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're this is kind of the wrap up slide. Okay. So where do we go from here? Um, first, we're we're um the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list. Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward. Now I'd um like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or should we move on? Mark, do you you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a there's only 11 people including the chairs and myself on this um, in this call, that we should open up this this whole to to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a a comment for more for more feedback from the entire working group community. So that we can make sure that everybody is aware um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my and and correct me if I'm wrong, um, either Asger or, um, Erik, um, what what I think we're we're saying is that we want to include a normative section that just says what to do if a message is received that is is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130, but then if that's not true, then I think we're going to keep 4130 and make this a new spec for for going forward, which would I think be Option A, have two— two specs, or a clean clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of a an option A.1 or something like that. It's not Or is it a two document approach? I don't know which which one it is specifically. Guys talk. I'm I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we it seems like we we've both Option A or Option B. Or is it Option A with saying that um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So for example, if if you are sending the first message and uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you. Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as may in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought. I still think, though, we want to open that to the um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from from the larger community before we start changing the specification. Um, Russ.
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, you read my my mind, Russ of it. Um, yeah, uh, I'm Okay, I have two comments. One is, uh, we really want to make sure that we are uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus. Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update um, 4130 with the new new security, right? Um, even if that breaks backward compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or ISG evaluation, it's not going to you're not going to pass it. I, as responsible AD, also would not even last call it. So, um, the, the, so I think we have a problem there, and I don't know what the I don't know I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that that is needed by the clients to say, "If I want to do 4130, I do I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way the way a lot of people solve this problem. So, uh, maybe maybe it's just mine my I don't understand how why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any have anything else to say? Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're this is kind of the wrap up slide. Okay. So where do we go from here? Um, first, we're we're um the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list. Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward. Now I'd um like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or should we move on? Mark, do you you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a there's only 11 people including the chairs and myself on this um, in this call, that we should open up this this whole to to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a a comment for more for more feedback from the entire working group community. So that we can make sure that everybody is aware um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my and and correct me if I'm wrong, um, either Asger or, um, Erik, um, what what I think we're we're saying is that we want to include a normative section that just says what to do if a message is received that is is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130, but then if that's not true, then I think we're going to keep 4130 and make this a new spec for for going forward, which would I think be Option A, have two— two specs, or a clean clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of a an option A.1 or something like that. It's not Or is it a two document approach? I don't know which which one it is specifically. Guys talk. I'm I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we it seems like we we've both Option A or Option B. Or is it Option A with saying that um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So for example, if if you are sending the first message and uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you. Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as may in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought. I still think, though, we want to open that to the um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from from the larger community before we start changing the specification. Um, Russ.
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, you read my my mind, Russ of it. Um, yeah, uh, I'm Okay, I have two comments. One is, uh, we really want to make sure that we are uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus. Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update um, 4130 with the new new security, right? Um, even if that breaks backward compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or ISG evaluation, it's not going to you're not going to pass it. I, as responsible AD, also would not even last call it. So, um, the, the, so I think we have a problem there, and I don't know what the I don't know I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that that is needed by the clients to say, "If I want to do 4130, I do I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way the way a lot of people solve this problem. So, uh, maybe maybe it's just mine my I don't understand how why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any have anything else to say? Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're this is kind of the wrap up slide. Okay. So where do we go from here? Um, first, we're we're um the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list. Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward. Now I'd um like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or should we move on? Mark, do you you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a there's only 11 people including the chairs and myself on this um, in this call, that we should open up this this whole to to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a a comment for more for more feedback from the entire working group community. So that we can make sure that everybody is aware um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my and and correct me if I'm wrong, um, either Asger or, um, Erik, um, what what I think we're we're saying is that we want to include a normative section that just says what to do if a message is received that is is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130, but then if that's not true, then I think we're going to keep 4130 and make this a new spec for for going forward, which would I think be Option A, have two— two specs, or a clean clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of a an option A.1 or something like that. It's not Or is it a two document approach? I don't know which which one it is specifically. Guys talk. I'm I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we it seems like we we've both Option A or Option B. Or is it Option A with saying that um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So for example, if if you are sending the first message and uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you. Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as may in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah. You read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe— maybe it's just my— my— I don't understand how— why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any— have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you— you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: What, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a, a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe— maybe it's just my— my— I don't understand how— why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any— have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you— you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my— and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a, a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update,_ um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe— maybe it's just my— my— I don't understand how— why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any— have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you— you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my— and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a, a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe— maybe it's just my— my— I don't understand how— why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any— have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you— you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my— and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a, a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update,_ um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe— maybe it's just my— my— I don't understand how— why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any— have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you— you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my— and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a, a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update,_ um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe— maybe it's just my— my— I don't understand how— why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any— have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you— you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my— and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a, a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe— maybe it's just my— my— I don't understand how— why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any— have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you— you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my— and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a, a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe— maybe it's just my— my— I don't understand how— why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any— have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you— you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my— and, and correct me if I'm wrong, um, either Asger or,_ um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a, a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update,_ um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe— maybe it's just my— my— I don't understand how— why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any— have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you— you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my— and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a, a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe— maybe it's just my— my— I don't understand how— why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any— have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you— you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my— and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a, a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about,_ uh, if he could or he wants to chime in about, _uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, _uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, _uh, you're supposed to update, _um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, _uh, _so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it.
So, _um, the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, _uh, to say, _uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, _uh, maybe— maybe it's just my— my— I don't understand how— why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any— have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, _um, the next thing is working group review and feedback. _Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, _um, if there's ambiguity that still needs to be resolved, we should raise those issues now, _um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, _um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, _um, like it open for any further questions and discussion. _Um, do you have any other questions or comments regarding anything we've covered, or, _um, should we move on?
Mark, do you— you have something else?
Marc Blanchet: Yeah, _um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, _uh, please enlighten me if, _uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, _um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. _Um, if you'd like I could take this slide, _um, for that, _um, that we did, this the document structure, and put it out as a, _a comment for more, _for more feedback from the entire working group community. So that we can make sure that everybody is aware, _um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. _Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, _uh, to me, this is a given. _Uh, I was trying to summarize the whole discussion. Did, _uh, have we reach consensus for an, _you know, _something, or we're still not sure exactly what would be the, _the structure of the document? That's to me at the moment is not clear, _uh, that we have a way forward at this point.
Debra Petta: From my— and, _and correct me if I'm wrong, _um, either Asger or, _um, Erik, _um, what, _what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, _um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, _for going forward, which would I think be Option A, have two— two specs, or a clean, _clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, _an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, _which one it is specifically.
You guys talk. I'm, _I've said enough.
Erik Wramner: Uh, _yes. _Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." _Uh, _but when we send, _it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, _because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, _uh, _an old system, _or you can send a message with the old standards and see what you get back, _or you send a message with the new standard which perhaps will not be understood and see what you get back. So, _some kind of of guidance on, _uh, _when it's okay to use legacy, _both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, _um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, _for example, _if, _if you are sending the first message and, _uh, _then it's okay if the user has configured that the other partner should use legacy, _then you can send legacy, _or when you receive a message and the header says this or that, _it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, _uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, _um, to the working group and get further discussion, considering that this is a, _a small group here today. _Um, we do want to make sure that we do get buy-in from, _from the larger community before we start changing the specification. _
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, _yeah, you read my, _my mind, Russ. _Um, _yeah, _uh, _I'm...
Okay, I have two comments. One is, _uh, we really want to make sure that we are, _uh, on the same page of what seems to be consensus here. So, right, _uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, _uh, if he could or he wants to chime in about, _uh, you know, a spec that could include SHA-1 or Triple DES as, _you know, _may implement.
Russ Housley: Uh, all right. _Um, _I highly likely— highly doubt that's going to get through, _uh, the IETF. _Um, _the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, _uh, _you're supposed to update, _um, 4130 with the new, _new security, right? _Um, _even if that breaks backwards compatibility. So, _uh, _so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. _
So, _um, _the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, _uh, to say, _uh, maybe it's a discovery mechanism that, _that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." _Um, _and that seems to be the way, _the way a lot of people solve this problem. So, _uh, maybe— maybe it's just my— my— I dont understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap up slide.
Okay, so where do we go from here? Um, first, we're, we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: What I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a, a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe— maybe it's just my— my— I don't understand how— why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a, a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a, a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a, a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a, a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
...and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered? Or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option Aor Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, an old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. Um, if you'd like, I could take this slide, um, for that, um, that we did, this the document structure, and put it out as a, a comment for more, for more feedback from the entire working group community. So that we can make sure that everybody is aware, um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, uh, to me, this is a given. Uh, I was trying to summarize the whole discussion. Did, uh, have we reach consensus for an, you know, something, or we're still not sure exactly what would be the, the structure of the document? That's to me at the moment is not clear, uh, that we have a way forward at this point.
Debra Petta: From my, and, and correct me if I'm wrong, um, either Asger or, um, Erik, um, what, what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, for going forward, which would I think be Option A, have two— two specs, or a clean, clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, which one it is specifically.
You guys talk. I'm, I've said enough.
Erik Wramner: Uh, yes. Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." Uh, but when we send, it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, uh, old system, or you can send a message with the old standards and see what you get back, or you send a message with the new standard which perhaps will not be understood and see what you get back. So, some kind of of guidance on, uh, when it's okay to use legacy, both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, for example, if, if you are sending the first message and, uh, then it's okay if the user has configured that the other partner should use legacy, then you can send legacy, or when you receive a message and the header says this or that, it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, um, to the working group and get further discussion, considering that this is a a small group here today. Um, we do want to make sure that we do get buy-in from, from the larger community before we start changing the specification.
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, yeah, you read my, my mind, Russ. Um, yeah, uh, I'm...
Okay, I have two comments. One is, uh, we really want to make sure that we are, uh, on the same page of what seems to be consensus here. So, right, uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, uh, if he could or he wants to chime in about, uh, you know, a spec that could include SHA-1 or Triple DES as, you know, may implement.
Russ Housley: Uh, all right. Um, I highly likely— highly doubt that's going to get through, uh, the IETF. Um, the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, uh, you're supposed to update, um, 4130 with the new, new security, right? Um, even if that breaks backwards compatibility. So, uh, uh, so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, you're not going to pass it. I, as responsible AD, also would not even last call it.
So, um, the, the, so I think we have a problem there, and I don't know what the, I don't know, I don't understand this protocol enough to understand why there isn't a transition mechanism, uh, to say, uh, maybe it's a discovery mechanism that, that is needed by the clients to say, "If I want to do 4130, I do, I go here. If I want to do 4130bis, I go over here." Um, and that seems to be the way, the way a lot of people solve this problem. So, uh, maybe, maybe it's just my, my, I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, um, the next thing is working group review and feedback. Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, um, if there's ambiguity that still needs to be resolved, we should raise those issues now, um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now I'd, um, like it open for any further questions and discussion. Um, do you have any other questions or comments regarding anything we've covered, or, um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, uh, please enlighten me if, uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. ...um, if you'd like, I could take this slide, ...um, for that, ...um, that we did, this the document structure, and put it out as a, ...a comment for more, ...for more feedback from the entire working group community. So that we can make sure that everybody is aware, ...um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. ...Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, ...uh, to me, this is a given. ...Uh, I was trying to summarize the whole discussion. Did, ...uh, have we reach consensus for an, ...you know, ...something, or we're still not sure exactly what would be the, ...the structure of the document? That's to me at the moment is not clear, ...uh, that we have a way forward at this point.
Debra Petta: From my— and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're, we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, ...um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. ...Um, if you'd like, I could take this slide, ...um, for that, ...um, that we did, this the document structure, and put it out as a, ...a comment for more, ...for more feedback from the entire working group community. So that we can make sure that everybody is aware, ...um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. ...Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, ...uh, to me, this is a given. ...Uh, I was trying to summarize the whole discussion. Did, ...uh, have we reach consensus for an, ...you know, ...something, or we're still not sure exactly what would be the, ...the structure of the document? That's to me at the moment is not clear, ...uh, that we have a way forward at this point.
Debra Petta: From my— and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, ...um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. ...Um, if you'd like, I could take this slide, ...um, for that, ...um, that we did, this the document structure, and put it out as a, ...a comment for more, ...for more feedback from the entire working group community. So that we can make sure that everybody is aware, ...um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. ...Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, ...uh, to me, this is a given. ...Uh, I was trying to summarize the whole discussion. Did, ...uh, have we reach consensus for an, ...you know, ...something, or we're still not sure exactly what would be the, ...the structure of the document? That's to me at the moment is not clear, ...uh, that we have a way forward at this point.
Debra Petta: From my— and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: From my, and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, ...you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, ...um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. ...Um, if you'd like, I could take this slide, ...um, for that, ...um, that we did, this the document structure, and put it out as a, ...a comment for more, ...for more feedback from the entire working group community. So that we can make sure that everybody is aware, ...um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. ...Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, ...uh, to me, this is a given. ...Uh, I was trying to summarize the whole discussion. Did, ...uh, have we reach consensus for an, ...you know, ...something, or we're still not sure exactly what would be the, ...the structure of the document? That's to me at the moment is not clear, ...uh, that we have a way forward at this point.
Debra Petta: From my— and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, ...um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. ...Um, if you'd like, I could take this slide, ...um, for that, ...um, that we did, this the document structure, and put it out as a, ...a comment for more, ...for more feedback from the entire working group community. So that we can make sure that everybody is aware, ...um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. ...Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, ...uh, to me, this is a given. ...Uh, I was trying to summarize the whole discussion. Did, ...uh, have we reach consensus for an, ...you know, ...something, or we're still not sure exactly what would be the, ...the structure of the document? That's to me at the moment is not clear, ...uh, that we have a way forward at this point.
Debra Petta: From my— and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: From my, and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, ...you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, ...um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. ...Um, if you'd like, I could take this slide, ...um, for that, ...um, that we did, this the document structure, and put it out as a, ...a comment for more, ...for more feedback from the entire working group community. So that we can make sure that everybody is aware, ...um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. ...Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, ...uh, to me, this is a given. ...Uh, I was trying to summarize the whole discussion. Did, ...uh, have we reach consensus for an, ...you know, ...something, or we're still not sure exactly what would be the, ...the structure of the document? That's to me at the moment is not clear, ...uh, that we have a way forward at this point.
Debra Petta: From my— and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to, ...you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: From my, and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: From my, and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: From my, and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, ...um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. ...Um, if you'd like, I could take this slide, ...um, for that, ...um, that we did, this the document structure, and put it out as a, ...a comment for more, ...for more feedback from the entire working group community. So that we can make sure that everybody is aware, ...um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. ...Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, ...uh, to me, this is a given. ...Uh, I was trying to summarize the whole discussion. Did, ...uh, have we reach consensus for an, ...you know, ...something, or we're still not sure exactly what would be the, ...the structure of the document? That's to me at the moment is not clear, ...uh, that we have a way forward at this point.
Debra Petta: From my— and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: From my, and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, ...um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. ...Um, if you'd like, I could take this slide, ...um, for that, ...um, that we did, this the document structure, and put it out as a, ...a comment for more, ...for more feedback from the entire working group community. So that we can make sure that everybody is aware, ...um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. ...Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, ...uh, to me, this is a given. ...Uh, I was trying to summarize the whole discussion. Did, ...uh, have we reach consensus for an, ...you know, ...something, or we're still not sure exactly what would be the, ...the structure of the document? That's to me at the moment is not clear, ...uh, that we have a way forward at this point.
Debra Petta: From my— and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: From my, and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, ...um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. ...Um, if you'd like, I could take this slide, ...um, for that, ...um, that we did, this the document structure, and put it out as a, ...a comment for more, ...for more feedback from the entire working group community. So that we can make sure that everybody is aware, ...um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. ...Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, ...uh, to me, this is a given. ...Uh, I was trying to summarize the whole discussion. Did, ...uh, have we reach consensus for an, ...you know, ...something, or we're still not sure exactly what would be the, ...the structure of the document? That's to me at the moment is not clear, ...uh, that we have a way forward at this point.
Debra Petta: From my— and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: From my, and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: From my, and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, ...um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. ...Um, if you'd like, I could take this slide, ...um, for that, ...um, that we did, this the document structure, and put it out as a, ...a comment for more, ...for more feedback from the entire working group community. So that we can make sure that everybody is aware, ...um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. ...Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, ...uh, to me, this is a given. ...Uh, I was trying to summarize the whole discussion. Did, ...uh, have we reach consensus for an, ...you know, ...something, or we're still not sure exactly what would be the, ...the structure of the document? That's to me at the moment is not clear, ...uh, that we have a way forward at this point.
Debra Petta: From my— and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, ...um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. ...Um, if you'd like, I could take this slide, ...um, for that, ...um, that we did, this the document structure, and put it out as a, ...a comment for more, ...for more feedback from the entire working group community. So that we can make sure that everybody is aware, ...um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. ...Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, ...uh, to me, this is a given. ...Uh, I was trying to summarize the whole discussion. Did, ...uh, have we reach consensus for an, ...you know, ...something, or we're still not sure exactly what would be the, ...the structure of the document? That's to me at the moment is not clear, ...uh, that we have a way forward at this point.
Debra Petta: From my— and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so [JWKS is the discovery mechanism we're talking about, right? So there needs to be a normative, documented way to say when the AS2 product is supposed to use the new default algorithms and when it is okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: I, I would like to do is, considering that there's a, there's only 11 people including the chairs and myself on this, ...um, in this call, that we should open up this, this whole to, to the entire working group to get more feedback. ...Um, if you'd like, I could take this slide, ...um, for that, ...um, that we did, this the document structure, and put it out as a, ...a comment for more, ...for more feedback from the entire working group community. So that we can make sure that everybody is aware, ...um, if those of you who have made comments would like to share them as well or however we want to get this information disseminated to the larger audience. I'd like to see that. ...Um, so that we, we're sure that everybody's on the same page.
Marc Blanchet: Right, ...uh, to me, this is a given. ...Uh, I was trying to summarize the whole discussion. Did, ...uh, have we reach consensus for an, ...you know, ...something, or we're still not sure exactly what would be the, ...the structure of the document? That's to me at the moment is not clear, ...uh, that we have a way forward at this point.
Debra Petta: From my— and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay to send it with an old version? I think it must be, ...because otherwise we can't sell this system to anybody. And then it's a configuration thing in the product where you say that the receiver is supposed to be, ...uh, ...an old system, ...or you can send a message with the old standards and see what you get back, ...or you send a message with the new standard which perhaps will not be understood and see what you get back. So, ...some kind of of guidance on, ...uh, ...when it's okay to use legacy, ...both when you are sending and when you are receiving.
Debra Petta: Okay. All right. So, we— it seems like we, we've both Option A or Option B. Or is it Option A with saying that, ...um, we put legacy interoperability guidance in a normative section?
Erik Wramner: I, I want to have it in a normative section. We don't need to have all the text in a normative section, but I think in the normative section, there needs to be text that tells the product when it is okay to use legacy. So, ...for example, ...if, ...if you are sending the first message and, ...uh, ...then it's okay if the user has configured that the other partner should use legacy, ...then you can send legacy, ...or when you receive a message and the header says this or that, ...it's okay to answer with a legacy. But, but it must be documented so that it's clear when it's okay and when it's not okay.
Debra Petta: Okay. Thank you.
Russ?
Russ Housley: Um, this sounds good to me, ...uh, to be in a normative section. I would only oppose putting SHA-1 as "may" in a normative section. Outside of that, defining rules, it's okay, you know, in a normative section.
Asger Smidt: And I agree as well. That sounds very good.
Debra Petta: Okay. That was easier than I thought.
I still think, though, we want to open that to the, ...um, to the working group and get further discussion, considering that this is a, ...a small group here today. ...Um, we do want to make sure that we do get buy-in from, ...from the larger community before we start changing the specification. ...
Russ?
Russ Housley: Uh, perhaps the chairs can summarize what was decided by this group and see if others on the mail list object.
Debra Petta: Okay. Mark.
Marc Blanchet: Uh, ...yeah, you read my, ...my mind, Russ. ...Um, ...yeah, ...uh, ...I'm...
Okay, I have two comments. One is, ...uh, we really want to make sure that we are, ...uh, on the same page of what seems to be consensus here. So, right, ...uh, I think we should have some clear writing about the possible consensus.
Second, without trying to point anybody, I would like to know the AD point of view here about, ...uh, if he could or he wants to chime in about, ...uh, you know, a spec that could include SHA-1 or Triple DES as, ...you know, ...may implement.
Russ Housley: Uh, all right. ...Um, ...I highly likely— highly doubt that's going to get through, ...uh, the IETF. ...Um, ...the, the, I'm struggling to find out what the issue is here, but the, the charter clearly says that you're supposed to update, ...uh, ...you're supposed to update, ...um, 4130 with the new, ...new security, right? ...Um, ...even if that breaks backwards compatibility. So, ...uh, ...so your charter says that, and I believe that if this goes to IETF last call or IESG evaluation, it's not going to— you're not going to pass it. I, as responsible AD, also would not even last call it. ...
So, ...um, ...the, the, so I think we have a problem there, and I don't know what the— I don't know— I don't understand this protocol enough to understand why there isn't a transition mechanism, ...uh, to say, ...uh, maybe it's a discovery mechanism that, ...that is needed by the clients to say, "If I want to do 4130, I do— I go here. If I want to do 4130bis, I go over here." ...Um, ...and that seems to be the way, ...the way a lot of people solve this problem. So, ...uh, maybe— maybe it's just my— my— I don't understand how, why we can't do that.
Marc Blanchet: Erik, go ahead.
Erik Wramner: Uh, yes. Uh, I think the legacy systems will not support JWKS. Uh, so, so that discovery mechanism will only ever work for new products. So, while we could use that, then if it doesn't find anything we will fall back to the old, then that should be described in the normative section of the new standard. So, so that it's clear for the product when it's supposed to talk the new default algorithms and when it's okay to fall back.
Debra Petta: Okay. Anybody else have any comments or questions? Should we move on to the next slide or does anybody else want any, have anything else to say?
Joe, next slide?
Joe Mandel: I was going to say, you want to move on to the next slide? I don't see anybody raising their hand.
Debra Petta: Okay. Yeah, let's do that. We're, this is kind of the wrap-up slide.
Okay, so where do we go from here? Um, first, we're we're, ...um, the next thing is working group review and feedback. ...Um, that's what we're doing right now. I'm presenting the changes to get your feedback, your questions, your concerns. If there are issues with how we've addressed the technical review, if there are implementation concerns we haven't considered, ...um, if there's ambiguity that still needs to be resolved, we should raise those issues now, ...um, as well as put them in the mailing list.
Um, and next, address any additional comments or concerns. Based on the feedback we receive from this presentation and comments from the mailing list, we'll prepare a version 02. I want to emphasize that this update version 01 represents our response to the first round of the detailed technical review. We've addressed the important issues that were raised, we've clarified areas that were ambiguous, ...um, we've improved the quality and maintainability of the specification, and we believe this is a good step forward.
Now, I'd, ...um, like it open for any further questions and discussion. ...Um, do you have any other questions or comments regarding anything we've covered? Or, ...um, should we move on?
Mark, do you, you have something else?
Marc Blanchet: Yeah, ...um, I'm not sure we have consensus or we have a clear outcome of the last slide discussion about document structure. So, ...uh, please enlighten me if, ...uh, you—
Debra Petta: From my, and, ...and correct me if I'm wrong, ...um, either Asger or, ...um, Erik, ...um, what, ...what I think we're, we're saying is that we want to include a normative section that just says what to do if a message is received that is, is a version 4130 type message, and refer them back to that. Now, I think that though we were thinking of doing with the spec was, ...um, deprecating 4130. But then, if that's not true, then I think we're going to keep 4130 and make this a new spec for, ...for going forward, which would I think be Option A, have two— two specs, or a clean, ...clean version 1.3 with a legacy appendix. Modern requirements only, normative. Oh, so we would make the legacy guidance non-normative, which is not really what we want. We want normative guidance within the spec that just says what to do if a message is received from a legacy partner, which is kind of an, ...an Option A.1 or something like that. It's not— Or is it a two-document approach? I don't know which, ...which one it is specifically.
You guys talk. I'm, ...I've said enough.
Erik Wramner: Uh, ...yes. ...Uh, you say "when a message is received", Debra, and that is pretty clear because when a message is received, you have an AS2 version in the message, so you know directly, "Okay, this is legacy," or "This is not legacy." ...Uh, ...but when we send, ...it also needs to be a way to say that when you send a message, is it okay