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 .

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.