3 ms·

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

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.

chatmasta 3y ago
> 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. [0] https://itero.plasmo.com/tools/generate-keypairs https://itero.plasmo.com/tools/generate-keypairs

chatmasta 3y ago

> 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. [0] https://itero.plasmo.com/tools/generate-keypairs https://itero.plasmo.com/tools/generate-keypairs