X.509 Technical Supplement

 

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

X.509 Technical Supplement

Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0

Microsoft Corporation

patterns & practices Developer Center
Web Service Security: Home
December 2005

Download	Download this guide in PDF format
Community	Web Service Security Community Workspace [Content link no longer available, original URL:https://go.microsoft.com/fwlink/?LinkId=57044]

Contents

Public Key Encryption and Digital Signatures
X.509 Certificates
Implementations of X.509
Certificate Authorities
Using X.509 Certificates in Patterns
More Information

The X.509 specification defines a standard for managing public keys through a Public Key Infrastructure (PKI). Public keys are maintained in X.509 certificates, which are digital documents that bind a subject's identity claims to a public key from a public/private asymmetric key pair. Identity claims are usually understandable by humans, such as a person's full name or e-mail address, or a machine host name or domain name. X.509 certificates are endorsed and issued by a trusted third party, which is known as a certificate authority (CA).

Public Key Encryption and Digital Signatures

Public key encryption, also known as asymmetric encryption, is based on a public/private key pair. The keys are mathematically linked, so that data encrypted with the public key can only be decrypted with the corresponding private key. X509 certificates use public key encryption as an alternative to shared symmetric keys, which are discussed in the Data Confidentiality pattern in Chapter 2, "Message Protection Patterns."

With public key encryption, the sender converts the plaintext message into ciphertext by encrypting it with the public key in the message recipient's X.509 certificate. The message recipient converts the ciphertext back into the plaintext message by decrypting it with the corresponding private key.

Figure 1 illustrates how public key encryption and decryption take place.

Figure 1. Public key data encryption and decryption

By using public key encryption, a message sender has assurance that only the recipient will be able to read the message.

In addition to providing data confidentiality through encryption, you can use the public key in the X.509 certificate to verify digital signatures created by a message sender. A digital signature is a value produced by the message sender to bind message data to the sender's identity and to provide a means of verifying the integrity of the message to detect tampering. In this case, the private key of the message sender is used to create the digital signature. The corresponding public key, which is found in the sender's X.509 certificate, is used to verify the signature. Digital signatures are used to assure the message recipient that the message originated from the identified sender, and that the message contents have not been altered since they were signed by the sender.

**Note   **With digital signatures that use public key cryptography, the origin of the signed message can be traced to the sender's identity, thereby satisfying nonrepudiation requirements. This differs from symmetric key integrity, where a message may have been signed by either party with knowledge of the shared secret key.

The public key can be distributed openly to encrypt messages and to verify digital signatures, but the private key in a key pair should be carefully guarded by its owner. This is necessary because it is used to prove the identity of the certificate subject and to decrypt messages that are intended for that subject.

Figure 2 illustrates the process of using public keys to sign a message.

Figure 2. Creation and verification of a digital signature

For a more detailed description of data confidentiality, see the Data Confidentiality pattern. For more details about digital signatures, see the Data Origin Authentication pattern.

X.509 Certificates

X.509 certificates contain several required and optional attributes that enable the identification of the subject. You can obtain the following list of attributes in an X.509 certificate:

• Version number: The certificate version.

  **Note   **Different versions (version 1, 2, and 3) of X.509 certificates have evolved over time, to provide additional security and attributes that are bound to the certificate. In practice, only version 3 certificates should now be used.

• Serial number: A unique identifier for the certificate.

• Signature algorithm ID: The algorithm used to create the digital signature.

• Issuer name: The name of the certificate issuer.

• Validity period: The period during which the certificate is valid. (This is typically set to be approximately one year.)

• Subject name: The name of the subject represented by the certificate. (The subject of a certificate is typically a person, an organization, or a Web/application server.)

• Subject public key information: The public key algorithm.

• Issuer unique identifier: The identifier for the issuer.

• Subject unique identifier: The identifier for the subject.

• Extensions: Extensions that can be used to store additional information. such as KeyUsage or AlternativeNames.

• Signed hash of the certificate data: The hash of the preceding fields encrypted using the issuer's private key, which results in a digital signature.

Custom security implementations that use X.509 certificates may depend on custom extensions that are not widely used or understood. These custom extensions must be included in the certificate by the certificate issuer when the certificate is created. Not all CAs may be willing or capable of adding custom extensions to certificates.

The validity period of an X.509 certificate tends to be much longer than that of other types of security tokens. For example, passwords are normally changed at shorter intervals, such as every 30 days. For this reason, it is critical to be aware of any possible compromise of an X.509 certificate private key, because it will be useful to an attacker for a considerably longer time than the secret key used in other security token types that have a much shorter lifespan.

Implementations of X.509

Security using X.509 certificates can be implemented at different layers of the network or application infrastructure, and each implementation had its own advantages and disadvantages.

Secure Sockets Layer (SSL)

SSL is a secure handshake protocol that supports X.509 certificates at the transport layer. It enables two parties to establish a session to communicate securely by providing confidentiality and data integrity. data origin authentication can also be provided if both parties use X.509 certificates. This is commonly referred to as SSL with client certificates. Some of the benefits of using SSL are:

• SSL is a well established protocol that is broadly interoperable, and is easy to configure and use.
• SSL has a performance advantage over message layer security because it is closer to the operating system than the message layer.

While SSL has some strong benefits, it does have the following liabilities:

• SSL operates point-to-point, which means that messages cannot be persisted in a secure state. It also means that SSL-encrypted SOAP messages cannot be processed by intermediaries without first being decrypted.
• If you use SSL in conjunction with WSE 2.0 or WSE 3.0 to provide data confidentiality and integrity at the transport layer, WSE cannot verify that SSL is being used to protect messages at the transport layer. Conversely, SSL cannot verify that clients are satisfying policy requirements defined in WSE, which is a requirement for client authentication.

WS-Security X.509 Binary Security Token

At the message layer, you can use X.509 certificates as binary security tokens in accordance with the WS-Security specification to sign and encrypt messages and to provide data confidentiality and data origin authentication.

The benefits of using X.509 at the message layer with binary security tokens include:

• Message layer security that uses X.509 certificates is flexible enough to provide point-to-point or end-to-end security. This allows messages to be persisted in a secure state for short periods for queue-based processing or for longer periods in an archived state.
• Message layer X.509 provides a high degree of interoperability. It provides standards based on the messages as they are sent over the wire instead of focusing on implementation for a particular platform.

Message layer security also has the following liabilities:

• Processing message layer security with X.509 certificates tends to have a greater impact on system performance than implementations that are lower in the protocol stack. This is because the message layer is further away from the hardware layer.
• Message layer security that uses X.509 certificates provides a great deal of flexibility, but it tends to be more complex to implement than security that uses X.509 certificates at other layers. This requires more knowledge of the underlying protocols, security policy, and programming against a Web services security API.

IPSec

IPSec provides a secure tunnel between two computers hosting applications that access resources or communicate with other applications. You can use X.509 in IPSec to authenticate hosts and negotiate a secure session between them. IPSec has some benefits that make it a viable security solution that uses X.509 certificates:

• Performance. IPSec benefits from better performance than security that is implemented further up the protocol stack, because it is closer to the hardware layer. It operates in the protocol stack between the data link and network layers.
• Ease of configuration. IPSec is easy to configure and implement on a number of platforms, including Windows Server 2003.

IPSec that uses X.509 certificates has a liability that must be considered:

• No fine control of security. IPSec policies are implemented based on a host computer instead of on a user or an application. IPSec that uses X.509 certificates is a viable option for providing secure communications between two hosts, but not for authenticating user or application subjects to make authorization decisions.

Certificate Authorities

Certificate authorities (CAs) are organizations that verify the identity of a subject that is represented in a certificate request, and that issue signed X.509 certificates. CAs can be internal or external to an organization. They can issue different types of certificates that are for a specific purpose or confer varying levels of trust. External CAs are typically commercial entities that provide certificate issuance to customers for a fee. Examples of external CAs include Thawte, VeriSign, and RSA.

CAs offer different "grades" of signed certificates for purchase. Some have a nominal fee and come with minimal requirements to prove the subject's identity. For example, a certificate that is used to sign e-mail messages may only cost a few dollars and require only e-mail confirmation to prove that the e-mail address represented by the subject in the certificate is authentic. A certificate that is used for more trusted activities may cost upwards of a hundred dollars and require a far more rigorous screening process to ensure that the subject meets the requirements for the certificate. Parties that want to use any type of certificate must decide that the criteria to qualify for such a certificate are sufficient for their needs, and that they consider the CA itself to be sufficiently reputable. The "grade", "class" or other term used by a CA to describe the quality or use of a certificate is often expressed as a certificate policy. A certificate policy describes the certificate's applicability to a set of security requirements for a given purpose. For more information about certificate policies, see Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework.

Internal CAs, such as Certificate Services in Windows Server, can simplify certificate management activities, but in this case the trust of the certificate is now based on the organization that issued it. Certificates that are issued for subjects within the organization's security domain (usually defined in Active Directory) are typically signed with the organization's root certificate or another "parent certificate" that is allowed to sign certificates. For more information about X.509 PKI services on Windows Server 2003, see Designing a Public Key Infrastructure.

The chain of certificates, from the subject's certificate to the root certificate that is used by the CA for signing subject's certificate, is known as a trust chain. A party may decide to trust certificates at any level within the trust chain. This allows them to trust certificates further down the chain, as long as they are able to trace the trust chain back to the level of the certificate they original trusted.

**Note   **In test environments, you may choose to use certificates that do not have rigorous requirements for proving the identity of the subject. Certificates can be generated and self-signed with the MakeCert utility. However, there are known performance issues when verifying digital signatures with certificates that are generated by the MakeCert utility. For more information about the MakeCert utility, see Certificate Creation Tool (Makecert.exe).

Obtaining an X.509 Certificate

Depending on the type of CA, X.509 certificates can be obtained in a variety of ways. For external CAs, certificates are typically obtained for a subject by submitting a certificate signing request (CSR). A CSR contains the subject's name, the public key, and the algorithm that is used. (The majority of X.509 certificates you are likely to encounter use RSA for its algorithm).

The public key included in the CSR comes from a public/private key pair, which is generated specifically for use with the requested certificate. As soon as the public/private key pair is generated, the private key should be immediately stored in a secure place, such as a machine key store. Access to the key should be solely restricted to authorized parties. Ideally, the only party able to access the private key file is the subject that is represented in the X.509 certificate, although some infrastructures may allow access to the certificate private key by other accounts. When parties other than the subject represented by the X.509 certificate are allowed to access the certificate private key, the ability to support nonrepudiation may not be possible. The public key of the public/private key pair is required for the CSR, but the private key should never be sent to the CA under any circumstances.

Internal CAs may also use CSRs to process X.509 certificate requests. However, because the CA is internal to a specific organization, there can be additional options that reduce the overhead that is required to process requests and verify subject identities. For example, an internal CA that uses Windows Certificate Server may enable autoenrollment, which automates certificate request and issuance for user accounts that are created within an Active Directory domain. For more information about Public Key Infrastructure and Windows Server 2003, see Public Key Infrastructure for Windows Server 2003.

Figure 3 illustrates the process of a subject requesting and issuing an X.509 certificate with a CA that processes CSRs.

Figure 3. Requesting and obtaining a certificate from a CA

Certificate Revocation

The issuing CA can revoke X.509 certificates if the integrity of the certificate has somehow been compromised. The justification to revoke an issued certificate varies with each CA, but some general causes for certificate revocation include the following:

• The private key has been stolen or wrongly disclosed due to improper storage or use. For example, when the subject's private key is attached to an outgoing message instead of its X.509 certificate that contains the public key.
• The subject represented in the X.509 certificate has breached the trust of the CA that issued the certificate. For example, if information about the subject was intentionally misrepresented to the CA during the process of verifying the subject's identity.
• An identity that corresponds to a certificate has been removed from an organization that manages an Internal CA. For example, a user account is removed from the system or is disabled when the user's employment is terminated.
• A subject no longer requires the certificate (cessation of operation). A CA may revoke a certificate if the certificate is no longer required and will not be used by the subject any more.

X.509 CAs typically publish a list of certificates that have been revoked, based on the CA's criteria for certificate revocation. These lists are known as certificate revocation lists (CRLs). CRLs are made publicly available so that a recipient can verify whether a certificate that was used to sign a message is valid. Any message recipient that receives a signed message should verify that the subject's certificate has not been revoked. This ensures the integrity of the signatures, based on the expected level of trust associated with the type of certificate.

In some situations, CAs may allow relying parties to query them directly to obtain the status of an X.509 certificate through an online revocation service (OLRS). A party that relies on this service communicates with the OLRS by using the Online Certificate Status Protocol (OCSP). If the CA offers access to an OLRS for the parties that rely on the service, it provides those parties with the ability to obtain the certificate status in real time instead of requiring them to download and cache CRLs published by the CA. One disadvantage of this approach is that it introduces a direct dependency upon the CA to be available to the parties that rely on it during the verification process. For more information about OCSP, see RFC 2650, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol—OCSP.

Certificate Storage and Access

X.509 certificates can be stored and accessed in a number of ways, including:

• Local repository. X.509 certificates may be exchanged out-of-band and stored in a locally accessible repository, such as the machine certificate store in the Windows operating system. You should only use a local repository if a small number of certificates are required for use by an online application.
• PKI server. Public Key Infrastructure (PKI) is a platform that allows an organization to centrally manage X.509 certificates that are required by the organization's services and subjects to authenticate and verify digital signatures. Certificates for that organization's subjects may also be made accessible outside of the organization. An example of a PKI solution is Certificate Services, which is included in Windows Server 2003. For more information about this PKI solution, see What Is Certificate Services?
• Direct presentation. X.509 certificates may be presented to a message recipient by attaching the certificate directly to the message. The recipient may subsequently decide to cache the certificate locally, pass it off to a central repository for storage, or simply reprocess it when it is attached to a new message.

Certificate Management

There are many issues related to certificate management and this section does not attempt to completely cover them. One issue that is significant to consider for message layer security is whether distinct certificates should be created for signing and encrypting message layer data.

For message-based security, it is a best practice to use distinct certificates and key pairs for encryption and digital signatures instead of a single key pair for both. One reason is that the contents of the certificates, as well as policies for issuance, key distribution, revocation, notification of revocation, and key backup are likely to differ depending on the purpose the keys are used for. This is particularly true when signatures are used for longer term authentication and integrity of business documents instead of merely temporary authentication of a session. Also, if encrypted messages are persisted to disk, you may need to decrypt the messages with an archived version of the private key. However, you do not want new digital signatures to be created with this private key.

Using X.509 Certificates in Patterns

Using X.509 certificates for authentication, data origin authentication, and data confidentiality is described in the following Web service security pattern documents:

• Brokered Authentication: X.509 PKI in Chapter 1, "Authentication Patterns."
• Implementing Message Layer Security with X.509 Certificates in WSE 3.0 in Chapter 3, "Implementing Transport and Message Layer Security."
• Implementing Transport Layer Security with X.509 Certificates and HTTPS in Chapter 3, "Implementing Transport and Message Layer Security."
• Implementing Direct Authentication with UsernameToken in WSE 3.0 in Chapter 3, "Implementing Transport and Message Layer Security."

More Information

For information about certificate policies, see "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework".

For information about X.509 PKI services on Windows Server 2003, see "Designing a Public Key Infrastructure" on Microsoft TechNet.

For information about the MakeCert utility, see "Certificate Creation Tool (Makecert.exe)" on MSDN.

For information about PKI and Windows Server 2003, see "Public Key Infrastructure for Windows Server 2003".

For information about the Online Certificate Status Protocol (OCSP), see "RFC 2650, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol—OCSP".

For information about the Certificate Services PKI solution in Windows Server 2003, see "What Is Certificate Services?".

For more information about certificates, see "What are certificates?" on the RSA Laboratories Web site.

For information about Secure Sockets Layer (SSL), see "What is SSL?" on the RSA Laboratories' Web site.

For more information about WS-Security version 1.0, see the OASIS Standards and Other Approved Work (including WS-Security) on the OASIS Web site.

For information about IPSec, see "Internet Protocol Security (IPsec) Operations Topics".

For information about the Internet X.509 PKI certificate and CRL profile, see "Internet X.509 Public Key Infrastructure Certificate and CRL Profile" (RFC 2459).

Kaufman, C., Perlman, R., and Speciner, M. Network Security - PRIVATE Communication in a PUBLIC World. Upper Saddle River, NJ: Prentice Hall PTR., 2002, ISBN: 0130460192.

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.