Certification authorities (CAs) are trustworthy persons or organizations that issue certificates to applicants whose identity has in some way been verified by the CA. Certificates are verified through a hierarchy of these CAs. Each certificate is linked to the certificate of the CA that signed it. By following this hierarchy, or verification path, to a known, trusted CA, you can be assured that a certificate is valid. An example of this is illustrated in the following diagram.

In this example, Netwerks’ certificate is certified by CA1, while Bob’s is certified by CA3. Netwerks knows CA1’s public key. CA2 has a certificate signed by CA1, so Netwerks can verify the CA2 certificate. The root also has a certificate signed by CA1. CA3 (Bob’s CA) has a certificate signed by the root. By moving up the verification chain to a common point (in this case, the root), Netwerks can verify Bob’s certificate.

Duties of Certification Authorities

Certification authorities have two main duties:

  • Publishing the criteria for granting certificates.
  • Granting certificates to applicants that meet the published criteria.

Other duties might include:

  • Managing certificates (for example, enrolling, renewing, and revoking them).
  • Storing root keys.
  • Verifying evidence submitted by applicants.
  • Providing tools for enrollment.
  • Accepting the liability associated with these responsibilities.

Obtaining Certification

To obtain a certificate from a CA, a software publisher must meet the criteria for either a commercial or an individual publishing certificate and submit these credentials to either a CA or a local registration authority (LRA). The criteria discussed below have been proposed by Microsoft. Note that standards bodies, such as the World Wide Web Consortium (W3C), are reviewing these criteria and they are subject to change. A description of the overall process of obtaining a certificate for code signing ends this section of the document.

Criteria for Commercial Certification

Applicants for a commercial Software Publishing Certificate (SPC) must meet the following criteria:

Identification Applicants must submit their name, address, and other material that proves their identity as corporate representatives. Proof of identify requires either personal presence or registered credentials.
The Pledge Applicants must pledge that they will not distribute software that they know, or should have known, contains viruses or would otherwise harm a user’s computer or code.
Dun & Bradstreet Rating Applicants must achieve a level of financial standing as indicated by a D-U-N-S number (which indicates a company’s financial stability) and any additional information provided by this service. This rating identifies the applicant as a corporation that is still in business. (Other financial rating services are being investigated.) Corporations that do not have a D-U-N-S number at the time of application (usually because of recent incorporation) can apply for one and expect a response in less than two weeks.

It is recommended that applicants generate and store their private key using a dedicated hardware solution. For example, this can be a magnetic stripe card, a plastic key with an embedded ROM chip (called a ROM key), or a smart card. For more information about storing keys, see Section 8.7 of Bruce Schneier’s book, Applied Cryptography.

How do large software publishers determine who should apply for certificates and who should sign code? The answers depend on how the software publisher wants to control distribution of the software on the Internet.

In a centralized approach, where the company wants total control of what code is published, there may be only one certificate, and strict guidelines for releasing code through one source. In a decentralized approach, software publishers might allow each division, or even smaller groups or individuals within the company, to sign their own code using the corporate name. The point is that the software publisher must decide who can apply for a certificate and sign code, and who takes responsibility for any code signed using certificates that bear the corporate name.

Using the Dun & Bradstreet rating as a criterion draws a line between “commercial” and “individual” developers. The intended distinction is between commercial persons or entities (that is, sole proprietors, partnerships, corporations, or other organizations that develop software as a business) and noncommercial persons or entities (that is, individuals or nonprofit corporations).

Criteria for Individual Certification

Applicants for an individual SPC must meet the following criteria:

Identification Applicants must submit their name, address, and other material that will be checked against an independent consumer database to validate their credentials.
The Pledge Applicants must pledge that they cannot and will not distribute software that they know, or should have known, contains viruses or would otherwise maliciously harm the user’s computer or code.

The value of an individual SPC is in the information it provides to users so they can decide whether or not to download the code. Knowing who authored the code, and that the bits have not been altered from the time the code was signed to the present, is reassuring information. Additionally, a browser could be used to access a publisher’s Web pages so the user can obtain detailed information about the signed code, the author, and the certificate authority. After learning about this code and the author, the user might decide to run the code, or all future code, coming from this particular individual.

The Application Process

These are the steps to apply for and grant a certificate:

  1. Apply for a SPC.A software publisher’s request for certification is sent to the LRA. (In a simpler model, it is sent to the CA.) It is expected that CAs and LRAs will have Web sites that walk the applicant through the application process. Applicants will be able to look at the entire policy and practices statements of the CA or LRA. The utilities an applicant needs to generate signatures, such as Authenticode, should also be available.The applicant must generate a key pair using either hardware or software encryption technology. The public key is sent to the LRA during the application process. For individuals, all of the necessary information can be transferred online. For commercial publishers, because of the identity requirements, proof of identification must be sent by mail or courier.
  2. Verify the applicant’s credentials.Depending on the contract between the CA and the LRA, these companies will examine the evidence to verify an applicant’s credentials. To do this, they may employ external contractors such as Dun & Bradstreet.
  3. Generate and issue the software publisher X.509 certificate.After the CA has decided that the applicant meets the policy criteria, it generates a SPC. The SPC contains multiple certificates conforming to the industry standard X.509 certificate format with Version 3 extensions. The SPC is distributed in a digital signature with the publisher’s software file to identify the publisher and provide the publisher’s public key. The digital signature is also used by the receiver of the file to verify that the file has not been modified since it was signed.The SPC is stored by the CA for reference, and a copy is returned to the applicant via electronic mail.The publisher should review the contents of the certificate and verify that the public key works with the private key. After accepting the certificate, the publisher should include a copy in all published software signed with the private key.

    Commercial developers can expect a response to their application in less than two weeks. While there is no limit to the number of certificates commercial software publishers can obtain, it is up to the publisher to determine who gets a certificate, and how code is signed and distributed.

  4. Distribute signed software.The publisher can now begin signing and distributing software on the Internet. Publishers use utility programs to sign the software they intend to publish. The utility programs use the private key to generate a digital signature on a digest of the binary file and create a signature file containing the signed content of a public key certificate standard (PKCS) #7 signed-data object. The PKCS #7 signed-data object also contains a copy of the SPC. For portable executable (PE) image format files, the PKCS #7 signature file contents are stored in the binary file itself, in an additional section.