Dear developers, product managers and manufacturers of PKI End Entity and Relying Party software,
The OpenXPKI team appreciates the growing interest in OpenXPKI as a backend RA/CA software from your industry. There have been some queries on this mailing list which indicate that some commercial users are actively using OpenXPKI as a backend for IoT/network device certificate provisioning. We find this exciting, and we are glad to see that our work on OpenXPKI is being appreciated. (Sadly, only few of these commercial users choose to actually support our project by involving the services of our company White Rabbit Security.) Based on our experience with the major PKI products available on the market, our team can confidently state that OpenXPKI is one of the most flexible and feature-rich enrollment backends for automated enrollment, supporting very flexible mechanisms both for authenticating and authorizing automatic enrollment requests (e. g. via SCEP or EST). White Rabbit Security has built amazing infrastructures with OpenXPKI for our customers, fully automating certificate renewal working seamlessly on end entity systems for more than a decade, and across Root rollovers. A huge amount of real world customer requirements and experience with actual implementations and projects has flown (back) into the development of OpenXPKI, in particular with regard to the automatic enrollment interfaces and the logic behind them. We believe that we really have understood the problem - and solved it properly. When working as PKI architects in our customer projects, our team is commonly faced with the challenge of securely provisioning groups of IoT/network devices with certificates within an organization, e. g. for telephones, desktop systems, printers or other devices. Over the time, our Architects have gained a lot of experience with various products on the market, and, frankly most of them suck. Big time. The products we are seeing are frequently lacking basic functionality to support a decent certificate life cycle, making the work of a PKI architect a pain, and requiring unnecessary concessions to defective client behavior. I do not accept that the deficiencies I observe are solely based on technological constraints. (In rare cases, yes, it may be true that due to limited resources on the end entities certain limitations will have to be employed.) A few examples, without naming manufacturer or product. If you *are* the manufacturer reading this, you probably will recognize your product. * Keystore management: - $product does not support multiple end entity key pairs. Interestingly I've seen this in surprisingly many products. I don't understand how a product is supposed to perform a proper certificate renewal without the ability of generating and enrolling a new key pair. Product manager: it is not an option to simply reuse the same key over and over again - and thus force the Issuing CA to support this, possibly violating its CP. * Trust management: - $product only supports one single Root CA as trust anchor - $product only supports self-created self-signed certificates created with the product software, effectively making it a closed shop which cannot be integrated at all in an organization's PKI - $product does not support certificate chains with arbitrary chain length. Product manager: do not make assumptions about the structure of customer PKIs - $product requires the distribution of subordinate CAs to the relying parties. Product manager: your end entities should send their certificate chain, the relying party shall only verify the supplied chain against the trusted roots * RFC compatibility: - $product does not honor certificate properties such as key usage or extended key usage properly. - $product requires asinine key usages such as DataEncipherment in the issued certificates and does not work without it. * Certificate lifecycle and enrollment/renewal automation - $product does not check validity/revocation status at all, neither on the EE cert nor on the chain certificates. Sadly, this seems to be the norm. - $product does not support authentication of a renewal enrollment request (with a new key) using the existing certificate and private key - $product does not provide any means of initial authentication of an end entity and assumes that anonymous enrollment requests are accepted by the CA. - $product assumes that certificate issuance happens synchronously/immediately and does not handle PENDING responses gracefully - $product supports challenge passwords in enrollment requests - but requires that the challenge password is static and shared by all end entities within the network * Algorithm and protocol support - $product does not support (RSA) keys > 2048 bit - $product still does not support TLS1.2 or TLS1.3 I could go on. The bottom line: it is generally a pain to work with IoT components and networking enabled devices. It is often extremely hard or even impossible to develop an architecture and system configuration which allows to properly secure the enrollment interfaces of the backend PKI system - mostly due to the product specific constraints. Product documentation regarding PKI capabilities is vague or non-existent. If it exists, it frequently exhibits hints that the manufacturer does not properly understand this certificate thingy at all. OpenXPKI ships with a default configuration which is a good starting point to design a system which properly supports initial certificate enrollment and secure certificate renewal. It is the job of a good PKI architect to design the system in a way that supports the projected use cases while maintaining the security of the system. OpenXPKI gives you all the tools, but real life then often forces to lower the guards. OpenXPKI is, as mentioned, extremely configurable, and it is possible to disable or circumvent all of the security mechanisms included in the default configuration. It is of course possible to reduce the security level of the enrollment interfaces to the level presented by some competitor PKI products which have been mentioned on the mailing list. End users of OpenXPKI are welcome to do so, but at their own risk. That said, we will not provide specific guidance how to reduce the security level of the OpenXPKI backend just to cater for IoT product deficiencies, IN PARTICULAR if this is queried in order to work around a product deficiency of an IoT software with insufficient and broken PKI support. If we *did* so, this reduced security would become a basic requirement to run your broken software with OpenXPKI, and I do not support that idea. Cheers Martin _______________________________________________ OpenXPKI-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
