Hi Alan, I've snipped your message, because I think we've gotten to a place where we're clearly talking past each other, as you claim I've said several things which I've most definitely not said, or expressed the opposite view. I'm hoping a reset here might help us find a more productive path forward, as well as figure out where the confusion started.
I think it's useful to go back to the original message from Owen, at https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM . Perhaps there are other messages and context I've missed, since this was cross-posted across two WGs, but that's the starting point. In that, I think we've got a path forward for interoperable EAP implementations: NAIRealm with id-kp-eapOverLAN asserted as an EKU. That gives a minimal sort of certificate profile to begin discussing. The question posed in that original message is what to do with extant certificates and extant practices, such as going to CAs used for TLS and asking for an id-kp-serverAuth cert, or supplicants looking for id-kp-serverAuth, and whether to specify that. My answer to that is categorically "no, don't do that". This is not specific to EAP, but part of the general problem of repurposing different trust hierarchies and different implementations, without addressing or mitigating the ecosystem considerations. For example, the use of such certificates outside of TLS can and will lead to them being revoked, because one of the requirements for such certificates is that they be used in TLS, otherwise they're revoked. Also, the changes to how PKI libraries validate TLS certificates, and the expectations for the issuance and management of such certificates, are at odds with the goals and objectives of interoperability being discussed. Reusing private key material across protocols and use cases does cause issues, just like reusing root certificates across trust purposes does cause issues. So using the TLS PKI is and always will be fraught with peril, and the maintainers of those TLS PKIs will disregard "your" concerns (the equipment, software, and users), because "your" use case is explicitly not supported and not supportable. These concerns aren't unique to EAP, by any means. But they're reasons why using id-kp-serverAuth is going down a route of trouble, and just because it's been done by some vendors doesn't mean it's good. A transition plan is always challenging, and the IETF is generally a poor venue for figuring out those logistics, because they're often rarely technical. For example, RFC 7585 exists: implementations "just" need to adopt it. Or, if the desire is to have an RFC describe what the end state should be, it should focus on that: describing the end-state. I don't think it should specify the intermediate states, because those are going to vary on a host of concerns, and worse, encourage folks to stop at the intermediate state as being 'good enough'. One such example of an intermediate state is using id-kp-serverAuth certificates, or trying to make a public/private CA demarcation. Those are bad steps to take. I'm not as optimistic as you are for suggesting 'all' EAP clients/supplicants are behaving and enforcing those extended key usages, so that doesn't seem too unreasonable. For example, wpa_supplicant doesn't seem to do so, in the versions used by ChromeOS, Android, or the current tip of tree (using either the internal or the OpenSSL implementation), and that seems like it probably covers quite a few devices/clients. In the TLS PKI, there's lots of industry experience on how to make changes. These changes often involve significant risk of breakage, and yet have become somewhat the norm, and with minimal practical impact. These can involve setting flag days, often starting as per-vendor flag days, such as was done with SHA-1. They can start with changes in major releases, such as new behaviours introduced in a major OS release or a major supplicant release to align closer to the specification or end-state. They may involve some of the intermediate steps mentioned, but only to the extent those are intermediate accomodations; for example, Chrome often has Enterprise flags that allow disabling standards-compliant behaviour when rolling out new versions, but only for a limited time and under limited situations. These aren't, I think, good things to specify, but they're certainly good things to share information about. I don't know if the IETF is the best place for that, but that's neither here nor there. However, an important part of those experiences is that things don't move until vendors break things. Yes, there needs to be a better path, but until you're willing to remove support for the old, or provide incentives for the new, your users don't and won't move. Hopefully that's easier to understand. I'm not sure how we ended up on such different pages, but I think the assertions and requests from your last message were a good indicator that we weren't even in the same postal code, let alone the same page, as far as discussions go.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
