canmove, Confirmed users
1,570
edits
Extension Manager:Addon Update Security:Signature: Difference between revisions
Extension Manager:Addon Update Security:Signature (view source)
Revision as of 22:38, 24 April 2008
, 24 April 2008→Update Public Key
| (6 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
In order to verify the signature in the update manifest, a public key is required. This must be included in the original add-on xpi. Including the key in the install.rdf makes checking for a key on install and retrieving the key at update time easier than the alternative option of including it as a file in the xpi. | In order to verify the signature in the update manifest, a public key is required. This must be included in the original add-on xpi. Including the key in the install.rdf makes checking for a key on install and retrieving the key at update time easier than the alternative option of including it as a file in the xpi. | ||
The | The SubjectPublicKeyInfo sequence (as defined in RFC 3280 and elsewhere) shall be DER encoded and then base64 encoded for inclusion as an em:updateKey resource in the install manifest. An example of this is below: | ||
<pre> | <pre> | ||
| Line 81: | Line 81: | ||
</RDF:Description> | </RDF:Description> | ||
</targetApplication> | </targetApplication> | ||
<em: | <em:updateKey>MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8tygA/cOMS/cyFn3Lf30Dskkd | ||
Q0i6NlLfKVxTYUmLge/tEb3QMHlBdM9D0mMpzybq7rFI7aFscUFEcDo9WVd5ieyZ | Q0i6NlLfKVxTYUmLge/tEb3QMHlBdM9D0mMpzybq7rFI7aFscUFEcDo9WVd5ieyZ | ||
cPotUd1WyUXZHXKluMfkE4asnXedLcICqrXEUJDxeWHSA36FrMW4uASxbl42/Ibi | cPotUd1WyUXZHXKluMfkE4asnXedLcICqrXEUJDxeWHSA36FrMW4uASxbl42/Ibi | ||
e/liyRgPpmzDged+jQIDAQAB</em: | e/liyRgPpmzDged+jQIDAQAB</em:updateKey> | ||
</RDF:Description> | </RDF:Description> | ||
</RDF:RDF> | </RDF:RDF> | ||
| Line 99: | Line 99: | ||
Because we are only outputting a fragment there is no xml prolog in the string. Additionally there is no declaration of the namespace prefixes used. The only two prefixes that should appear are <code>RDF</code> and <code>em</code>. | Because we are only outputting a fragment there is no xml prolog in the string. Additionally there is no declaration of the namespace prefixes used. The only two prefixes that should appear are <code>RDF</code> and <code>em</code>. | ||
The serialised string is "pretty-printed" xml. This is done for readability in diagnostic situations. Essentially each child tag is indented one level above it's parent tag. The level of indent chosen is 2 spaces. The rules for outputting the rdf as set out in the next section ensure that an element only ever contains character data, or a number of child elements, never both. | The serialised string is "pretty-printed" xml. This is done for readability in diagnostic situations. Essentially each child tag is indented one level above it's parent tag. The level of indent chosen is 2 spaces. The rules for outputting the rdf as set out in the next section ensure that an element only ever contains character data, or a number of child elements, never both. Lines are separated by a single \n character regardless of platform. | ||
If the element contains only character data then it is outputted as a single line with spaces at the start indenting the tag to one level of indent higher than that of the parent element. If the literal data happens to contain newlines then it is still outputted as is, i.e. no attempt to indent the character data is performed. | If the element contains only character data then it is outputted as a single line with spaces at the start indenting the tag to one level of indent higher than that of the parent element. If the literal data happens to contain newlines then it is still outputted as is, i.e. no attempt to indent the character data is performed. | ||
| Line 113: | Line 113: | ||
</pre> | </pre> | ||
If the element contains other elements then the start and end tag each appear on a line by themselves (indented one level deeper than the parent element). Each child element will then appear as specified, one level of indent deeper. | If the element contains other elements, then the start and end tag each appear on a line by themselves (indented one level deeper than the parent element). Each child element will then appear as specified, one level of indent deeper. | ||
<pre> | <pre> | ||
| Line 141: | Line 141: | ||
There is one main issue with this serialisation. It cannot handle the situation where resources are referenced from multiple places or recursively. Resolving both of these would require coming up with a method of generating anonymous uri's that were not random in nature. Neither of these issues are possible with the current update RDF schema. | There is one main issue with this serialisation. It cannot handle the situation where resources are referenced from multiple places or recursively. Resolving both of these would require coming up with a method of generating anonymous uri's that were not random in nature. Neither of these issues are possible with the current update RDF schema. | ||
=== Example output === | |||
Given the following example update RDF: | Given the following example update RDF: | ||
| Line 538: | Line 540: | ||
Since DSA cannot be used with the SHA512 hashing algorithm we should use RSA key types. | Since DSA cannot be used with the SHA512 hashing algorithm we should use RSA key types. | ||
=== Signature Format === | |||
The signature format is very similar (but not identical) to the format of a certificate. In ASN.1 syntax, the required signature is: | |||
<pre> | |||
ManifestSignature ::= SEQUENCE { | |||
signatureAlgorithm AlgorithmIdentifier, | |||
signatureValue BIT STRING } | |||
</pre> | |||
where signatureAlgorithm and signatureValue are as defined in RFC 3280. | |||