Private keyfile format

[David Brown <da...@linaro.org>]

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

Re: Private keyfile format

["Dr. Flywheel" <dr...@gmail.com>]

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 <da...@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
> > >
>

Re: Private keyfile format

[David Brown <da...@linaro.org>]

On Fri, Nov 10, 2017 at 07:58:28AM -0200, Fabio Utzig 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?

Fortunately, it seems it is pretty easy to just support both.  There
aren't any changes to the use of the tool, it is able to detect the
key format just by the header line in the PEM file.  Adding support
for the new format will just be adding an entry.

David

Re: Private keyfile format

[Fabio Utzig <ut...@apache.org>]

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 <da...@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
> >

Re: Private keyfile format

["Dr. Flywheel" <dr...@gmail.com>]

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 <da...@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
>