Eliot Lear <l...@cisco.com> wrote: > [+iotops] > > Brian, > > On 21 Apr 2021, at 00:22, Brian Smith <br...@briansmith.org> wrote: > > Eliot Lear <lear=40cisco....@dmarc.ietf.org> wrote: > >> The issue for me is library support. If libraries take the doc too >> seriously, it screws the apps that really need to do the right thing for >> their use cases. >> >> > What you're trying to prevent is the entire purpose of this, as I had > originally proposed it. The goal is to have library developers feel > comfortable removing the CN-ID support completely from their libraries. > > > Thanks for being crisp in stating your intent. > > Let's turn the question around, because perhaps I am missing something. > Bearing in mind that there are literally hundreds of millions of devices > with long-lived certificates fielded today, what advice would you give to > those who support applications that have to interact with them? What harm > comes to any use case for there to be a non-default library flag, as Victor > mentioned there is with OpenSSL? >
I suspect OpenSSL would continue to do what it does because it does all kinds of stuff to support legacy implementations. My interest is in developing software for the Web PKI (what browsers do, roughly) and similar new systems where CN-ID isn't useful. Note that RFC 6125 and a rewrite of it wouldn't be relevant to the legacy systems that were designed before RFC 6125, or that were designed after RFC 6125 but chose to ignore the advice in RFC 6125 and so became legacy systems before they even shipped. I would claim that there are three unacceptable outcomes: > > - Causing the app developers to write their own X.509 validation code > – they’ll get it wrong. > - Freezing app developers on old versions of the libraries – we want > app developers to update. > - Library developers ignoring the IETF. Let’s not give advice they > simply cannot follow. > > Most developers will be able to take the advice to avoid CN-IDs. It is becoming common for libraries to ignore CN-IDs by default (e.g. Golang's library [1]) or to not support them at all (in the case of webpki [2]). > By the way, one reason many of these devices have long lived certs is that > they might sit in inventory for long periods of time before they are ever > taken out of the box. There are other reasons, as well. Burned in certs > can be there as a base level anti-counterfeiting measure, for instance. > And yes, there are lots of issues with burned in anything, but there are > engineering tradeoffs to be made. > > To Jim’s point, maybe it would be possible to say that the flag should be > unavailable for certs issued after a certain date, but that date would have > to be well into the future, and coordinated at least with IEEE. That seems > like a lot of work for something that, as Rich rightly alludes, is really a > vendor decision to intelligently make. > Are those certificates using the Subject Common Name field to identify a DNS name or an IP address, without having the subjectAltName populated? If not, then this proposal wouldn't affect them. This isn't saying "You must have a subjectAltName no matter what;" it's saying "You must have a subjectAltName using dNSName (iPAddress) to identify a subject by DNS name (IP address)." To your point that we should have a 10 year deprecation period: RFC 6125 was published just over 10 years ago, and already discouraged using the subject common name for DNS names and IP addresses. So I think we've already lived through the 10 year deprecation period. [1] https://golang.org/doc/go1.15#commonname [2] https://github.com/briansmith/webpki Cheers, Brian -- https://briansmith.org/
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
