On Wed, Dec 13, 2017 at 11:53 AM, Michael Richardson <[email protected]> wrote:
> > Kathleen Moriarty <[email protected]> wrote: > > Thank you for addressing Russ' Gen Art comments. With that, I'm > wondering if a > > recommended signature algorithm should be specified. This change > had the work > > go from just supporting RSA to including other (and better) choices. > > I don't think we should recommend anything, or really need to. > There is only a small interoperability issue with algorithm selection here. > > The manufacturer (in the form of the MASA) must generate a signature that > their product (the pledge) is able to verify. > > So the selection of signature algorithm is essentially driven by the > capabilities of the pledge. The manufacturer knows what that is, and so > can > select appropriately. > > There are tradeoffs of bandwidth, power consumption, code size, and > longevity > of algorithm, and I think that specific recommendations should be left to > those closer to the specific kind of deployment. A choice for a home NAS > device intended to be sold immediately and deployed (with a ~5 year > lifespan) > might have significant differences than for a 50-port 10GE switch to be > deployed in a secured data center after being warehoused for 10 years as a > spare. > > The voucher contains a pointer to the owner (the Registrar) within it, and > I > think that algorithm will be subject to a different set of constraints. > > The intermediate system (JRC, or Registrar) is given the opportunity to > audit > the resulting voucher. As such, it needs to be able to verify the voucher, > and it is here that we have some interoperability issue if the manufacturer > picks an unusual algorithm. The Registrar could deny the new device, > consult with a human for an exception, or something more complex. > > Finally an additional constraint is that the MASA's signing infrastructure > may need to have the private key available, and so some kind of HSM might > be > appropriate, and those do not unfortunately track the bleeding edge of > cryptography. > > Personally, I'd like to recommend edwards25519 (RFC8032), but tooling is > not up to that today. That leaves one debating between size of RSA > >2048bit, > vs security of secp256k1 Nit: you mean secp256r1, i.e., P-256. Typically we don't use k1, though bitcoin does... -Ekr ... depending upon code space and hardware > acceleration available in target device. One would want to pick the same > algorithm as for SUIT and other stuff. > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > >
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
