Before we dive into the specific question, let me clarify your initial statement. Snap are signed and snapd checks it before installation. This process assures the snap about to be installed is the one uploaded, reviewed and assigned with a unique revision by the store. The trust-path is established cryptographically between snapd and the Store, i.e. the snap is signed by the Store, derived from authenticated, secure and auditable uploads from snapcraft.
That said, there are also mechanisms in place for allowing accounts (users) to sign specific contents when it’s necessary or desirable. These primitives are already used for creating devices (models), validate snaps and optionally sign builds (revisions).
Is it possible to extract a signing key to store/import it elsewhere?
Yes, create/register/list/export mechanisms are in place. However their usefulness depend heavily on which process you have in mind.
Once a key is registered, does the store refuses unsigned snaps?
Snaps are always signed, it’s not optional. They can be optionally signed by the publisher and we have planned work to also optionally check publisher signature before installation (obs: in practical terms, it would be just checking a further link in the trust chain, since the publisher key is also trusted via the Store key)
Can we rotate theses keys? More precisely, can we register a new key and make the old one invalid?
You can register new keys right now (commands you identified) but revocation is done via manual request if and when they get compromised. Work on complete key-management features is planned but not yet prioritized.
Are the signatures checked by the snapd clients, or only on the store?
Snapd clients check them before install or refresh.
What are “assertions” in the context of snaps?
Assertions are the internal documents (cryptographically signed) representing all the global aspects of snaps trusted by the whole ecosystem (client, server, 3rd-parties). For instance, the snap_id of a given name, or given a hash/digest of a snap blob reviewed by the store, what is the (snap_id, revision) and so on.
While crucial to snaps security, assertions are rarely exposed in day-to-day operations, they are meant to be processed by machines
I hope the answers above clarified your points and the SnapStore and Snapd teams are available to discuss requirements with any ISV interested in directly (re-)signing snaps with their own keys and potentially establishing additional (out-of-band) security.