Method to verify a signed archive's X.509 CoT I am trying to understand the key high level details behind verifying trust when downloading an archive. 

This is my understanding of how it could be done:

On the Software Developer side:


Obtain a certificate from a public CA like verisign
Generate a hash of your archive and then encrypt this string using the private key from your certificate, this is the "signature"
Host the archive for download, along with a separate file which contains the public key from your certificate + the signature generated in step 2. 


On the (user) client side:


Download and unpack the archive, download the signature + public key file
Decrypt the downloaded signature using the downloaded public key, save this value
Iterate through the public root certificates embedded within your operating system. For each root certificate, decrypt the signature value and compare the result to the result in step 2. 
Once a match is found in 3, you have verified that the author's private key descends from the chain of trust of the CA which you found matched in step 3
Note: This all assumes that the software developer used a CA for which we have an embedded root certificate in our clients OS.


Questions:


Is the above method sound, or am I overlooking key details?
Given a blank slate client, if I wanted to combine the public key + signature + archive into a single file that I could make the client understand and parse, are there any widely supported formats to leverage for organizing this data?
On the Software Developer side:


  Obtain a certificate from a public CA like verisign


Yes, you could use a CA, but you could also host your own CA. You'd of course need your clients to trust this CA.

Obtaining a certificate is probably more economic in the long term though.


  Generate a hash of your archive and then encrypt this string using the private key from your certificate, this is the "signature"


The signature generation in general contains the hashing operation. The hash algorithm is a parameter to the signature generation algorithm. The hash doesn't need to be encrypted, for instance ECDSA is not used for encryption.

Sometimes a hash tree is used instead - the hash over the data is not directly signed, but the hash is included in a structure also containing meta data (e.g. the MIME type of the data), and that structure is signed.


  Host the archive for download, along with a separate file which contains the public key from your certificate + the signature generated in step 2. 


No, you'd leave the public key within the certificate. You can used either attached or detached signatures (see below).

On the (user) client side:


  Download and unpack the archive, download the signature + public key file


Right. Except that the public key file would be a certificate.


  Decrypt the downloaded signature using the downloaded public key, save this value


See above, decryption is not always used.


  Iterate through the public root certificates embedded within your operating system. For each root certificate, decrypt the signature value and compare the result to the result in step 2. 


The chain is probably longer than two certificates (containing intermediate / server certificates), and certificates helpfully contain one or more "Issuer" fields to look up the higher level certificate. So there is no need to search for the root certificate top-down.


  Once a match is found in 3, you have verified that the author's private key descends from the chain of trust of the CA which you found matched in step 3 Note: This all assumes that the software developer used a CA for which we have an embedded root certificate in our clients OS.


Yes, by verifying the signatures in the certificates, but also validate CRL's for revocation, validate that the certificate is within the validity period, etc. etc.

Questions:


  Is the above method sound, or am I overlooking key details?


Yes, see above.


  Given a blank slate client, if I wanted to combine the public key + signature + archive into a single file that I could make the client understand and parse, are there any widely supported formats to leverage for organizing this data?


For systems using PKIX (Public Key Infrastructure using X5.09 certificates as issued by - for instance -Verisign) the best known container format is probably CMS, the Cryptographic Message Syntax.

There are of course various package managers (or "stores" nowadays) that may describe how software needs to be signed or otherwise managed. It could well be that they in turn use CMS to sign the software, but other protocols may be used as well.