Re: [Iotops] [Uta] How should we change draft-ietf-use-san?

[Eliot Lear <[e-mail]>]

[+iotops]

Brian,

> On 21 Apr 2021, at 00:22, Brian Smith <[e-mail]> wrote:
> 
> Eliot Lear <lear=[e-mail] <mailto:[e-mail]>> 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 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.

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.

Eliot