On Wed, Dec 13, 2017 at 3:12 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > On Wed, Dec 13, 2017 at 11:53 AM, Michael Richardson <mcr+i...@sandelman.ca> > wrote: >> >> >> Kathleen Moriarty <kathleen.moriarty.i...@gmail.com> 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.
Thanks for the explanation, this makes sense and it was a non-blocking question. I'm fine with this response and leaving the document as-is. Kathleen >> >> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> > -- Best regards, Kathleen _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
