The extension ID is derived from a private key that the developer uploads with the first upload to the app store, and the ID will change if any subsequent uploads include a different key.pem in their zip file (but if there is no key.pem then the extension ID will remain the same).
the original owner might transfer the private key to the new owner. And since Google doesn't require each upload include the private key, then the new owner could push changes without even needing access to that key.
This isn't how PKI works. Is this really an accurate description of the way private keys are used for Chrome extensions? That you're supposed to provide the private key in a PEM file when you upload the extension?
The developer should be signing the extension/manifest with the private key and sharing the public key/including the public key in the upload. Updates should continue to be signed with the private key, and as long as the key doesn't change, the original public key from the original upload can be used to verify that the same private key was used to sign -- if the public key is included or not on subsequent uploads is immaterial. Yes, the developer could sell/share the private key with someone else, thereby allowing someone else to provide a legit, signed update, but that's the risk (to the user of the extension/message recipient) of the signer not keeping their private key private. Sharing the private key with Google, or anyone, undermines provenance of the extension. Sharing the private key with someone else wouldn't be detectable, because use of the private key to sign is the method by which the identity of the source is established.
The problem is that this isn't just a code signing system. In a code signing system, the public key would be tied to a developer, and they could rotate their private key to sign their app. But in this case, the extension ID itself is tied to a (private) key, so it's not even possible for the developer to rotate their key without changing their extension ID, which breaks existing installations and breaks interoperability
for code that expects the extension pages at chrome-extension://{extensionID}
In a code signing system, the public key would be tied to a developer, and they could rotate their private key to sign their app.
That's also not how PKI works. The private key and the public key are tied together, by the very math that defines public/private key cryptography. There is no situation where a private key can be changed and the associated public key does not change. Are you confusing public keys with certificates?
It makes sense that the extension id is/could be tied to a keypair: that forces a change in identity of the source of the extension if the key changes. However, that's not very extensible or pragmatic, so I suspect that the extension is identified by a field in a certificate, the certificate is signed by Google, the certificate is assigned/tied to a developer, and that would allow the certificate fields to stay constant while allowing the keys to be rotated.
> Are you confusing public keys with certificates?
No. If you include a key.pem file (private key) in your .zip on first upload, then the extension ID is derived from the public key which is derived from the private key. This is an RSA keypair, there is no certificate involved, and the process to generate the extensionID is well known (hex encoding of first 32 characters of the public key). [0] The chrome team signs the .crx file, so they need the private key to do it.
However, AFAICT, this is _optional_ (and also poorly documented, so probably also discouraged). You can choose not to submit your zip with a key.pem file, in which case I presume Google will use a more modern PKI approach on their backend. But they still don't give you the private key.
As an extension developer, the reason you want to upload the key.pem yourself is so you can know the extension ID before you publish it, which might be important if your extension contains code that references that ID (e.g. checking Origin of a postMessage is chrome-extension://{yourId}).
Disclaimer: I haven't published an extension, so this is based only on reverse engineering and reading the threads in the extension developers Google Group.
the original owner might transfer the private key to the new owner. And since Google doesn't require each upload include the private key, then the new owner could push changes without even needing access to that key.
This isn't how PKI works. Is this really an accurate description of the way private keys are used for Chrome extensions? That you're supposed to provide the private key in a PEM file when you upload the extension?
The developer should be signing the extension/manifest with the private key and sharing the public key/including the public key in the upload. Updates should continue to be signed with the private key, and as long as the key doesn't change, the original public key from the original upload can be used to verify that the same private key was used to sign -- if the public key is included or not on subsequent uploads is immaterial. Yes, the developer could sell/share the private key with someone else, thereby allowing someone else to provide a legit, signed update, but that's the risk (to the user of the extension/message recipient) of the signer not keeping their private key private. Sharing the private key with Google, or anyone, undermines provenance of the extension. Sharing the private key with someone else wouldn't be detectable, because use of the private key to sign is the method by which the identity of the source is established.