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... 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 =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
