Talk:Extension Manager:Addon Update Security:Signature
Here are some comments on the page User:Mossop:Fx-Docs:AddonUpdateSignature
There are certain essential details that are missing.
Q1. What is the required/expected ASN.1 syntax of the key that is DER encoded and base64 encoded?
A1. It is a SubjectPublicKeyInfo sequence (as defined in RFC 3280 and elsewhere) and NOT a simple RSAPublicKey sequence (as defined in PKCS#1) nor as a simple DSAPublicKey . (That's a good definition. It's just missing from the document.)
Q2. What is the required/expected syntax of an RSA signature?
A2. According to the example, it is the raw binary RSA signature, base64 encoded. It is not encoded as an ASN.1 bit string, and so is not the same signature format at that used in certificates in RFC 3280. Neither is it encoded as an ASN.1 "encryptedDigest" (an octet string) as defined in PKCS#7, nor as a "SignatureValue" (also an octet string) as defined in RFC 3852. Whether leading zero octets are to be suppressed or not is not specified.
Q3. What is the required/expected syntax of a DSA signature?
A2. Unknown. The answer is not given in the page. The example does not illustrate. A DSA signature has two parts, named 'r' and 's', each of which is exactly 20 bytes. Perhaps they are to be concatenated into a single 40-byte binary block, as done by SSL 3.0, or perhaps they are to be ASN.1 encoded as a sequence of two integers, as in the Dss-Sig-Value in RFC 2246 (TLS).
Other issues of cryptographic significance:
1. The page gives an example of an RDF/XML construct that contains a key. I am not sure, but I think that construct is called an "install-manifest". This install-manifest appears to have many of the properties of a public key certificate. It appears to be a binding of a contributor name, and one or more product identifiers, to a public key. However, the manifest itself is not cryptographically protected. It is not signed. I imagine this is because it is intended to be downloaded via https, and the copy downloaded is presumed to be valid at the source server. That's not unreasonable. However, if it was signed, it would also offer detection of alteration after downloading. Also, IINM, there is another proposed standard that defines a certificate entirely encoded in XML. One wonders if that standard should be used rather than inventing yet another.
2. The page shows an example of an RDF/XML construct that contains a signature and also other information (GUIDs and http URLs). This does not appear to be the same RDF/XML construct as the first one (which contained the key), but I could not find a separate name for it (both XML constructs appear to be called manifests). As I understand it, the signature applies to the content of the same XML construct in which it appears, the content that precedes it in that construct. So, the signature ensures the authenticity of those GUIDs and http URLs, but not the content of the download(s) obtained from the http URL(s).
It was not apparent to me how those GUIDs or http URLs ensure the authenticity of the content downloaded from the http URLs. What stops a download from one of those http URLs from being modified in transit? What ensures that the user who downloads the content of those http URLs is actually getting content from the expected server? I expected that the signed data would include at least a digest (a hash) of the download, but that is not apparent. It occurred to me that the thing that looks like a GUID could actually be an MD5 hash. But it is called an "id", so I doubt that.
Some answers for you:
1. Yes the key is contained in the install manifest which is the original extension installed by the user. This manifest format is that already in use by add-ons for previous versions of Firefox and other Mozilla applications and it was important to make the manifest continue to work on those previous versions, thus just the addition of the updateKey property to it.
2. The signed manifest is the update manifest. This is the update information that is automatically retrieved periodically to find updates for the add-on. It is necessary to sign the update manifest because it can be retrieved over insecure channels. The final downloaded updated add-on (the xpi file) is protected by virtue of the fact that it must either be available on a https url, or there must be a hash provided for the xpi.
Dave, I agree that it is reasonable to require that "it must either be available on a https url, or there must be a hash provided for the xpi." but (unlesss I'm misunderstanding it) the example given on User:Mossop:Fx-Docs:AddonUpdateSignature has neither. It has http URLs, not https, and I see no hashes in it. Where's the protection? Where are the signed hashes in the example?
Please specify the expected/required syntax of a DSA signature. /Nelson