On Thu, Feb 16, 2012 at 9:13 AM, Stephen Farrell <[email protected]> wrote: > > > On 02/16/2012 01:51 PM, Phillip Hallam-Baker wrote: >> >> My first thought was that this should be done by the CA. > > > In the cited material, they also cover PGP and SSH keys and > not every CA will have a collection beyond its own end > entities so I don't think this is a CA function since its > not checking one public key, but one public key against > a population of keys and is independent of X.509, PGP, SSH > etc. > > >> Then it turns >> >> out that these are all (apparently) embedded systems generated keys >> and only some of those are CA certified. So maybe there is a need for >> this protocol. > > > That too.
Problem being that it is probably easier to implement a RNG right than to implement any additional protocol for checking. Or at least the only people who are likely to implement your protocol are people who (1) would do the RNG right or (2) are required to for an audit requirement. It would be really nice if there was some way to audit RNGs algorithmically... >> As I have mentioned before though, public key is problematic in >> embedded systems. Most of the systems don't have the resources to do >> the job right and this will only get worse as time goes on because as >> a $1 processor gets more powerful a chip with a 6502 core gets cheaper >> and more are made. More 6502 type chips were made last year than in >> any previous year. >> >> >> So my view is that we have to get away from the idea that the endpoint >> has to do public key crypto. > > > Well, that's one position but not necessarily the only one > with merit. Well certainly it is better that they do have a PKI stack but only if they do it right and that puts us way above what a PIC controller class chip with only a few Kb can be expected to do. Hence we need to have two tracks. Rather than telling people that they must do PKI on 16 bit chips, maybe have a different approach there. -- Website: http://hallambaker.com/ _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
