mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: "Jan Lübbe" <jlu@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [RFC 2/4] Add rsa support
Date: Fri, 13 Mar 2015 11:25:43 +0100	[thread overview]
Message-ID: <20150313102543.GA23879@ns203013.ovh.net> (raw)
In-Reply-To: <1426241455.13791.103.camel@pengutronix.de>

On 11:10 Fri 13 Mar     , Jan Lübbe wrote:
> On Fr, 2015-03-13 at 10:56 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > Having an ASN1 parser for DER/x509 is a huge amount of complexity I
> > > would not want in a bootloader. Just take a look at the problems the
> > > SSL-CAs and browsers had with different interpretations of the same
> > > cert.
> > 
> > der is nothing few under lines
> 
> Sorry, I can't parse this.
> 
> > x509 a few more as it's based on DER
> 
> Could you show me that code?
let me finish to clean it
and rebase it
> 
> > > The FIT format (and corresponding public key in the bootloader's DT) has
> > > been adopted by depthcharge and u-boot, because it handles the
> > > requirements and nothing more.
> > 
> > if you want to add this format you can but via the keychain loader not in the
> > code as today you do have soc such as imx that store the key in OTP as DER
> 
> The IMX does not store keys in OTP. It stores a SHA(1 or 256) hash over
> a table of "super root keys". This is irrelevant for barebox, as this is
> already handled by the ROM code.
it's does as you can use it as hw IP to check the kernel

yes you store a hash but you do can use it in barebox.

other SoC (i can mention the name NDA) does store the key in the OTP of the
SoC programmed at production time of the SoC itself.
with HW RSA accelerator
> 
> > and u-boot is not the best reference EVER.
> 
> Depthcharge is much more relevant here, as it's used as a coreboot
> payload on chromebooks.

does not make it more relevant is the term of key format

the Standard are x509, PGP and der/pem for ages

and as said we can support it but make it the only one NO WAY
> 
> > > What is your use-case for which you need to add keys at runtime?
> > 
> > simple you want to allow user to put their own key
> > or use a CA to handle allowed key
> >
> > if you want to replace grub this is critical
> 
> We have customers which require that do not allow runtime loading of
> keys. So it should be possible to disable runtime loading at compile
> time. 
yeah of cource but the feature need to be here IMHO

and honestly to respect the opensource if you allow this you MIGHT be
compliant with GPLv3

it's more user friendly
For my own customer I always recommand to have a board uniq key that you
can provide to each end customer upon request to it can install it's own
linux. Even if the key is not replaceble.

Best Regards,
J.
> 
> Regards,
> Jan
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> 

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2015-03-13 10:26 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-12 14:39 [RFC 0/4] FIT Support Jan Luebbe
2015-03-12 14:39 ` [RFC 1/4] digest: Make filename arguments const Jan Luebbe
2015-03-13  7:40   ` Sascha Hauer
2015-03-12 14:39 ` [RFC 2/4] Add rsa support Jan Luebbe
2015-03-12 17:47   ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13  9:35     ` Jan Lübbe
2015-03-13  9:56       ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 10:06         ` Sascha Hauer
2015-03-13 10:12           ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 10:22             ` Jan Lübbe
2015-03-13 10:26               ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 10:10         ` Jan Lübbe
2015-03-13 10:25           ` Jean-Christophe PLAGNIOL-VILLARD [this message]
2015-03-13 10:43             ` Jan Lübbe
2015-03-13 15:49               ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 10:00                 ` Jan Lübbe
2015-03-16 10:27                   ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 11:25                     ` Jan Lübbe
2015-03-16 11:33                       ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 15:42                         ` Jan Lübbe
2015-03-17 10:48                           ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-17 12:09                             ` Jan Lübbe
2015-03-17 12:39                               ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-17 12:57                                 ` Jan Lübbe
2015-03-12 14:39 ` [RFC 3/4] FIT: add FIT image support Jan Luebbe
2015-03-12 18:19   ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13  9:28     ` Jan Lübbe
2015-03-13 10:05       ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 10:21         ` Jan Lübbe
2015-03-13 14:28           ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 15:41             ` Jan Lübbe
2015-03-13 16:08               ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 10:19                 ` Jan Lübbe
2015-03-16 11:14                   ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 12:08                     ` Jan Lübbe
2015-03-16 12:19                       ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 13:28                         ` Jan Lübbe
2015-03-16 13:51                           ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 14:31                             ` Jan Lübbe
2015-03-16 14:40                               ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 14:50                                 ` Jan Lübbe
2015-03-13 11:33         ` Marc Kleine-Budde
2015-03-13 15:54           ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 16:06             ` Marc Kleine-Budde
2015-03-13 17:00               ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 10:04                 ` Jan Lübbe
2015-03-16 10:28                   ` Jean-Christophe PLAGNIOL-VILLARD
2015-12-29 10:18   ` Yegor Yefremov
2015-03-12 14:39 ` [RFC 4/4] FIT: add test config and data [do not merge] Jan Luebbe
2015-03-12 14:51 ` [RFC] digest: Add enum Jan Luebbe
2015-03-12 17:50   ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13  9:54     ` Jan Lübbe
2015-03-13 10:10       ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 18:50         ` Robert Schwebel
2015-11-11 11:39 ` [RFC 0/4] FIT Support Yegor Yefremov
2015-11-13 11:35   ` Antony Pavlov
2015-11-13 12:54   ` Sascha Hauer
2015-12-29  8:10     ` Yegor Yefremov
2016-01-05  8:11     ` Marc Kleine-Budde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150313102543.GA23879@ns203013.ovh.net \
    --to=plagnioj@jcrosoft.com \
    --cc=barebox@lists.infradead.org \
    --cc=jlu@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox