Please consider: In open source development there is always a conflict between discipline and convenience, as well as between standardization and innovation. Over the last few decades I laid my eyes on millions of lines of code that were littered with #ifdef and nested #ifdef statements and "build configuration" files that were un-fathom-ably complex. Code and "build" complexity are the number one cause for proliferation of code security attack vectors. I encourage consideration of decisions affecting continued maintenance of "legacy" code to be examined through the eyes of "security". It is always easier to plug security holes in code implementations that follow a well accepted and reviewed standard, since many more security-minded people are available to scrutinize the implementation and many more test tools are already deployed in the field. My opinion, is that main-line code should follow as many standard specifications as possible, when it comes to security features. Innovation and non-standard variations can persist in various side branches or be included in individual developer's private branches. If we want to see our code being accepted as a quality product that can successfully compete in the marketplace, I advise giving discipline an advantage over convenience when it comes to security features. Legacy features are the "Achilles Heel" of security.
Thanks. --Dr. Flywheel On Fri, Nov 10, 2017 at 1:58 AM, Fabio Utzig <ut...@apache.org> wrote: > I don't think forcing users to change existing key formats would be a > good idea. I would suggest leaving compatibility in place for the > moment. When MCUboot changed the image format for 1.0 a new flag was > added to "new create-image" command, "-2", to write in the new format. > Maybe if a user provides "-2" you could also assume that PKCS#8 is to be > used. This would only break Mynewt users that have switched to MCUboot, > which is likely a smaller user base and more willing to engage in > "breaking" changes. What do you think? > > On Wed, Nov 8, 2017, at 05:15 PM, Dr. Flywheel wrote: > > My vote is to affect the change ASAP. I don't know how painful it would > > be > > for other developers; however, carrying legacy implementations forward > > only > > increases the window of security vulnerability. Best to do this now, > > before > > the volume of applications exacerbates the situation. > > > > Thanks. > > > > --Dr. Flywheel > > > > On Wed, Nov 8, 2017 at 10:14 AM, David Brown <david.br...@linaro.org> > > wrote: > > > > > In my work on https://runtimeco.atlassian.net/browse/MCUB-87 I will be > > > adding support for password protected private key files to MCUboot's > > > image signing tool. I would also like to add this support to `newt` > > > as well. > > > > > > In order to support this protection, I will likely be moving from the > > > current algorithm-specific "legacy" file formats for private keys to > > > PKCS#8 (https://tools.ietf.org/html/rfc5958: Asymmetric Key Packages), > > > which defines a key storage format that supports multiple algorithms. > > > It also has a more modern and robust method of password protecting the > > > files. As per the OpenSSL documentation: "newer applications should > > > use the more secure PKCS#8 format...". > > > > > > For MCUboot's tool, I will likely convert the format of the key files > > > to always be PKCS#8, effectively removing support for the legacy > > > formats. There will be a documented `openssl` command that can be > > > used to convert any keys between the different formats. > > > > > > My question for the mynewt list is whether it would be acceptable to > > > change this key format within 'newt', or if we will continue needing > > > to support the legacy file formats for some period of time. > > > > > > Thanks, > > > David > > > >
