AMO/SigningService

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

Add-on Signature System

Hi. This project is the AMO piece of the larger Add-on Signature System. Please read that document so the rest of this wiki page makes sense.

We will need to modify several pieces of AMO and its libraries in order to accommodate this new system. Those changes are roughly laid out below and divided up into phases. See the diagram below (which compares to Marketplace for a reference) for a high level view:

Notes:

• The flows are very similar. Apps load a certificate from disk and get signed. For add-ons we'll load a certificate from disk, but we'll generate a new certificate as well, use the loaded certificate to sign the new certificate, and then sign the add-on with the new certificate.
• When we're done signing we discard the new certificate.
• Any pre-existing signatures on the add-on are replaced. This includes developers who have signed the add-on with a valid AMO certificate already. The expected flow for self-hosting in addition to AMO hosting is to download the signed add-on from AMO, not do any manual signing.
• We don't do any signing before the add-on is approved for the public. Reviewers are expected to use developer versions or debug versions of Firefox so won't need to have the add-ons signed to test them.
• Should not need any API changes since this is all after add-on review
• We're looking at high 10s to low 100s of signed packages per day

Roadmap

Phase 1: Signing with Trunion

Current Status	Needs Bugs Filed
Owners	Ryan Tilder, Wil Clouser

Summary:

We currently don't sign add-ons at all on AMO, but we do sign apps on the Marketplace using trunion and could use the same system (with modifications). A rough summary of the Trunion overview is as follows:

 1. This CA will be entirely automated and self contained
     1. The CA's root certificate will be hard coded into Firefox/Fennec
        in a similar manner to the privileged FxOS apps
     2. For every request to sign an addon:
          o a brand new 2048 bit or stronger RSA key pair will be
            generated by the signing service
          o the ephemeral public key will be certified by this CA
          o the ephemeral private key generated will then be used to
            sign the addon archive in Mozilla's own bastardized
            implementation of JAR signing that we know as "XPI signing"
          o the freshly certified ephemeral public key will be included
            in the addon as part of the signature chain
          o the ephemeral private key and certificate are thrown away

In practical terms, this means:

• Modifying Trunion to accept meta-data about what it is signing (at least an add-on ID)
• Modifying Trunion to send meta-data about what it signed (at least the certificate serial number)
• Modifying Trunion to generate certs on-the-fly

Open Bugs:

Full Query

ID	Priority	Status	Summary
1070155	P1	RESOLVED	Define and document the API for add-on signing
1076052	--	RESOLVED	Add Python key & certificate generation to trunion
1123915	P1	RESOLVED	Where should we put "Preliminary" in the cert?
1124321	--	RESOLVED	trunion addon signing: ephemeral certs are missing all attributes but CN
1126894	--	RESOLVED	Create parallel "preliminary" addon signing trunion instance for dev
1135926	--	VERIFIED	Hide existing signature warning until relevant
1158467	P1	RESOLVED	Signed extensions on AMO have invalid signatures (And cause to many crashes for Fx28 and older versions)
1158938	P1	RESOLVED	End mozilla.sf with two newlines

8 Total; 0 Open (0%); 7 Resolved (87.5%); 1 Verified (12.5%);

Phase 2: Initial AMO Support

Current Status	Needs Review

• Modifying the Validator to warn about pre-existing signatures which will be clobbered
• Modifying the Reviewer Tools to send add-on data to Trunion and using the returned data to save a signed add-on to disk (API to Trunion needs definition)
• Modifying AMO to add a signing script which will sign the latest versions of existing add-ons to bootstrap the system
• Modifying MDN by adding any necessary documentation about this project

Phase 3: Blocklist

Current Status	Needs Review

Summary: This system expects to use the blocklist until a more official cert revocation system can be implemented. Blocklist administration will use the administrative scaffolding it currently uses. A new top level item will be added called <certificates>. An example entry is below:

 <certificates>
   <certificate blockID="100">
     <issuer>mozilla.com</issuer>
     <serialnumber>00245EADBDE07F113DEE</serialnumber>
   </certificate>
 </certificates>

Phase 4: Non-AMO hosted add-ons

Current Status	TBD

Summary:

• This needs payments from Marketplace
• This needs UX