1) Partly their reason is surely reducing the attack surface. But it's also a good way to milk the market, if you are the de-facto monopolist. Cannot tell which has more weight for them, for us the outcome for the user is not acceptable, especially for cases like this article describes, which is afaik not the first time this happens. There are various safety mechanisms in place for Nitrokey's update mechanism. One is signing, but there are others (secure boot alike) mechanisms which not only verify the firmware during flashing, but also during each boot.
2) there no 448 available on the OpenPGPCard on the Nitrokey 3 (yet) - cannot give an ETA
3) We try to not take positions here and currently we also don't have to - generally the OpenPGPCard is mostly independent from these "schism" as all host tools should obey this specification. But I might be wrong or not getting your question entirely - so why are you assuming there might be two different keys in future?
1) Partly their reason is surely reducing the attack surface. But it's also a good way to milk the market, if you are the de-facto monopolist. Cannot tell which has more weight for them, for us the outcome for the user is not acceptable, especially for cases like this article describes, which is afaik not the first time this happens. There are various safety mechanisms in place for Nitrokey's update mechanism. One is signing, but there are others (secure boot alike) mechanisms which not only verify the firmware during flashing, but also during each boot.
2) there no 448 available on the OpenPGPCard on the Nitrokey 3 (yet) - cannot give an ETA
3) We try to not take positions here and currently we also don't have to - generally the OpenPGPCard is mostly independent from these "schism" as all host tools should obey this specification. But I might be wrong or not getting your question entirely - so why are you assuming there might be two different keys in future?