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?

  • 1
    You're probably looking for RSA – BlueWizard Dec 15 '18 at 20:08
  • 1
    What signing process you use will depend on what is going to process the signature. So, what are you needing the code signing to do? – schroeder Dec 15 '18 at 21:13
  • As far I can think of: Using different keys to sign different parts of components in the system. Distributing the signed packages through third party sites or pages. Easy revoking of signing keys or signed certificates. The system being considered would be a typical u-boot/kernel/rootfs Linux system. The signing process will be executed on build servers. The signed signatures are processed by the embedded target Linux systems. – minghua Dec 18 '18 at 4:47

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.

|improve this answer|||||
  • I post this as a partial answer, in wishing that experts will come up with a better answer or provide feedbacks to make this answer more complete. Questions: Is this process secure enough? How can it be improved? – minghua Jan 22 '19 at 17:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.