Software Signing Standards

Question

Is there a software signing certificates standard, officially or by popularity?

As I understand the SSL/TLS/https certificates rules are specified by the RFCs. Mixed use of servers and clients from different vendors will just interoperate without a problem. Does such kind of standard ways exist for software signing?

Or is that each software OS would use their own way of signing and need the package vendors to follow? Or ask in a specific situation, if the package signing is working well on a Linux system, would it work on other OS or platforms?

Answer 1

The RFC's dont technically deal with standards for code signing or TLS/SSL per se. Rather, they set the standards for x.509 certificates and PKI. Such as how you should construct a x.509 certificate using asn1 (RFC 5280) and then how it should be encoded to create a certificate.

The standards for TLS/SSL and code signing certificates which are issued by Certificate Authorities (CA's) such as GlobalSign, Digicert, Sectigo, etc are subject to the CA/B forum Baseline requirements. Code signing certificates for the Windows ecosystem fall into this category.

However, if you are signing code on Linux you might be using a PGP certificate and key to apply the signature. In this scenario, you would be using the PGP web of trust instead of CA's.

As I understand the SSL/TLS/https certificates rules are specified by the RFCs. Mixed use of servers and clients from different vendors will just interoperate without a problem. Does such kind of standard ways exist for software signing?

Code signing, document signing, TLS/SSL, S/MIME, are all examples of different types of x.509 certificates being used for different purposes. The x.509 certificate and key files are essentially cross platform because they all adhere to the same RFC's on how to construct and use the files. You can use the x.509 certificate to apply a digital signature to a file. How to construct digital signatures is (I think) in RFC 2315.

Or is that each software OS would use their own way of signing and need the package vendors to follow? Or ask in a specific situation, if the package signing is working well on a Linux system, would it work on other OS or platforms?

How each OS handles the signatures varies. Windows requires code to be signed using a code signing certificate issued via a CA. If the code is executing at the kernal level, then you have to buy a EV Code Signing certificate and submit the code to Microsoft for review. Linux however does not require code to be signed by a code signing certificate. Instead, Linux uses the PGP web of trust to verify PGP signatures in the repository. Packages ported from Linux to Windows will not be trusted on Windows because Windows doesnt use the PGP web of trust. Same in reverse, Windows applications ported to Linux will not be trusted unless you sign it with a PGP key and you import the PGP certificate into the clients PGP keystore. Apple also has its own requirements and you can find their documentation here.

Answer 2

Preliminary I can see there is no such a standard for softwares from different companies. Standards from each of the software vendors could exist, but not in publicly available documentations. Probably you need to sign-up to a code-signing package from a vendor to exercise the process to find out more. Even though that probably will not be straight and simple to find out the signing details because most of the packages poorly document the internals than just showing you the steps.

The signing key most likely will be RSA, as @BlueWizard pointed out in the comment.

The signed certificate, should contain the subject public key with other directives or meta-information. The subject public key should be verified by the signer public key.

Let's use a subject as an example who produces software. A sequence of steps could be:

• [1] The subject submits the subject public key to the authority signer.
• [2] The authority signer put the subject public key with some meta-information together, and encrypt it with the signer private key. This produces a certificate. The certificate is returned to the subject.
• [3] The subject puts the hash of a to-be-signed software image with the certificate into an unsigned or to-be-signed package.
• [4] The subject encrypts the unsigned package with its own private key.
• [5] The subject publishes the signed package and its signing public key.
• [6] The receiver decrypts the package with the package signing public key. Then decrypts the certificate with the authority public key. If the decrypted certificate message contains the obviously verifiable meta information the validation is successful. The meta-information put in by [2] and verified here probably will contain the name of the signing authority and the name of the subject, when the certificate was signed, and when its validity shall expire, what it should be used for, etc.

An exception to the above is that, if the package signing key used at [4] is different from the certified key, the subject needs to encrypt the signing public key using the certified private key. This creates an intermediate certificate.

The meta-information involved in [2] and [6] should be specified by the signing and validation standard.