This looks cool -- thanks for sharing.

Are there any docs about the threat model or intended security properties of this system? It seems at first glance like the trusted computing base includes the machine that this is running on (and thus storing the user keys and weights) but it would be great to clarify or call this out explicitly.

If a server is compromised you would have to invalidate all the private keys it used, because you can't know if the attacker still has the key. Unless the server never had access to those keys beyond using them. The difference is that an attacker who gained shell access could have copied your private key material if you didn't use a HSM, and you would never be the wiser.

With a Hardware Security Module (HSM), the keys can only be used, not copied. There is a hardware barrier that prevents such access. The only way to get those keys is to physically steal the HSM.

While true the attacker could still have used the the keys to sign his/her own files. Maybe key invalidation is in order regardless?

I'm not sure about the YubiHSM, but it is considered good (essential?) practice to have a hardware signature counter, so you can tell if there were signatures that done outside of your normal-process (which, if important, would document those).

So, you'd know if there are bad signatures out there; If your process documents all signatures, you'd even know which ones are bad (because they are bad in the audit trail or do not appear there at all).

Yubikeys have such a counter, so I'd be surprised if the YubiHSM doesn't.

YubiHSM keeps an audit log of all the data it’s been asked to find. If you find it’s been used to improperly sign a certificate, you can add that specific certificate to your CRL.

Ah, yeah that makes sense :)