Evolving PKI Standards
Posted by
in Citizen eID, Digital Certificates, Government Authentication, PKI, Public Key Infrastructure, SSL
April 1, 2015
0
The World of PKI Standards
Public Key Infrastructure (PKI) facilitates security services across a global community of users and across various applications. As such, standards are a key requirement for the success of PKI. Without standards for PKI data structures, trust management and interoperability, the use of PKI would be severely limited and may never have experienced the success it has over the past 20-25 years.
Public Key Infrastructure (PKI) standards have evolved significantly over the past 25+ years. The initial standard was a relatively simple one, defined as a common base to support multiple applications. As individual applications and user communities adopted PKI technology, they fed additional requirements into the standards bodies, resulting in a number of updates to that base standard. In addition, some applications that have specific unique requirements have developed their own standards or standard profiles for use in their specific application. The ICAO electronic passport standard is one recent example.
What’s in a Standard?
All PKI standards created over these years cover at least the following main subjects:
• Certificate content and format
• Certificate revocation
• Trust models
All public-key certificates contain at least a public-key, identification of the subject/holder of that key, identification of the Certification Authority (CA) that issued the certificate and time period during which the certificate can be used. All certificates are digitally signed by the issuing Certification Authority (CA). Some certificates are issued to end-entities, such as human users or devices. Other certificates are issued to CAs, enabling certification paths to be constructed between a locally trusted CA and the remote CA that issued the certificate of interest.
Certificate revocation is a mechanism to shorten the validity period after a certificate has been issued. If, for example, an employee leaves the company, or the corresponding private key is compromised, the CA will likely want to revoke the corresponding certificate for the remainder of the published validity period. In some environments, rather than perform certificate revocation, CAs issue only certificates with very short initial validity periods, eliminating the need to revoke them.
PKI standards support a number of trust models including hierarchical, distributed, bridge etc. The appropriate trust model depends largely on the application in which PKI is being deployed or the community of users that will be taking part.
X.509 – The Base Standard for PKI
The initial “base standard” for PKI, developed jointly by the International Telecommunication Union (ITU) and International Organization for Standardization (ISO) was published in 1988. This standard, commonly referred to by its ITU identifier “X.509” (ISO identifier is 9594-8) defined a simple format for public-key certificates that enabled them to be distributed widely and enabled users to verify their authenticity and integrity. The certificates, digitally signed by the issuing Certification Authority (CA) contain a public-key, the identity of the key holder and the validity period of the certificate. The CA also regularly publishes a digitally signed Certificate Revocation List (CRL) identifying certificates that had to be revoked prior to the end of their validity period. As certificates can be issued to CAs as well as end-entities, certification paths can be constructed and any of the trust models supported. The original driver for this standard was the ITU-T X.400 secure messaging standard. However the base standard was defined to support any application, not just the X.400 requirements.
Establishing Trust Among User Communities
In the 1990s, as more communities of users began to adopt PKI, and the requirement to establish trust among user communities emerged, a number of requirements for enhancement to the base X.509 standard were identified. The U.S. Federal Government, for example, established a PKI infrastructure to connect the various government departments together and to bridge that integrated infrastructure with external PKI user communities. Trust needed to be manageable and constraints to control the boundaries of the interconnected user community needed to be possible. A set of extensions was added in the 3rd edition of X.509 (1997). Certificate extensions included constraints on the use of the public-key, constraints on the certification paths that could be constructed, alternative names associated with the certificate issuer and the certificate subject, link from the certificate to the appropriate CRL etc. CRL extensions included the ability to partition the set of revoked certificates across a set of smaller CRLs, identification of the set of certificates covered by a specific CRL, ability to issue interim delta CRLs and the ability to identify a CRL issuer other than the CA that issued the certificates. This milestone was the only time that the actual certificate and CRL structures were modified. Because of the addition of an optional field for the extensions, the versions were updated to version 3 certificates and version 2 CRLs. The extension mechanism is flexible and enables new features to be added to certificates and CRLs in a backward compatible way. Although there have been several updates to the X.509 standard the versions for certificate and CRL formats remain the same today. This consistency in versions is critical to interoperability and any future enhancements to the standards must also be done within the framework of existing versions.
The Internet PKI
Although the X.509 standard can be used in various applications, it makes no statement about which features/extensions should be mandatory or optional. The Internet Engineering Task Force (IETF) saw the need for specific interoperability profiles tailored for Internet applications. The IETF profile for “The Internet PKI” has, in fact, become adopted globally as the de facto base profile for certificates and CRLs far beyond its original intent. One reason for this is likely it is a general purpose profile intended to support generic Internet applications and at least provides some guidance on mandatory requirements, while not being over-restrictive or application-specific. Another contribution reason may be that IETF RFCs are available free over the Internet while the current version of the X.509 standard must be purchased. This IETF specification has itself undergone 2 revisions. The current specification is RFC 5280 published in 2008. Previous versions were RFC 2459 published in 1999, and RFC 3280 published in 2002. The IETF also defined some application-specific profiles for Internet applications such as secure messaging (S/MIME) and Transport Layer Security (TLS) supporting the authentication of websites. RFCs were also defined for PKI operational protocols including certificate management protocols, as well as Online Certificate Status Protocol (OCSP), an alternative to CRLs for revocation status checking.
Passports & Smartcards
Other standards groups and industry forums have developed specifications for their own environments. Generally these specifications tend to be based on the X.509 base standard as well as the IETF profiles and additional protocols. One example is the International Civil Aviation Authority (ICAO) and its specifications for electronic passports. In that application, a digitally signed copy of data about the document, the document issuer and the document holder is stored on a contactless IC within the passport. The associated certificates and CRLs are made available to border control so the digital signature can be verified and the data validated. For border control, this makes uncovering impersonation more reliable and identification of fraudulent documents easier. The PKI supporting this ICAO application is quite simple. Each country operates a single CA and that CA signs certificates for Document Signers that sign the passport data. There are no intermediate CAs, eliminating the need for most certificate extensions and simplifying the validation process significantly.
In addition to the base X.509 certificate format, some different formats have been defined to satisfy specific requirements where X.509 isn’t the best fit. One example is the ISO 7816 card-verifiable certificate format. This format better suits environments where certificates will be processed on chips in smart cards, passports etc. These certificates tend to be smaller than X.509 certificates, have shorter validity periods and have no revocation scheme. One application where this certificate format is being used is the authorization of access rights to sensitive fingerprint biometrics on travel documents within the European Union. Because certificate validation is done on the passport chip, their existing ISO 7816 file system and library can be re-used and additional X.509 validation library is not required. Given that these chips have much more restrictive processing capabilities than a computer typically used for validation in an X.509 PKI environment, use of the ISO 7816 PKI rather than X.509 is critical.
With terrorism a high priority for governments globally, secure passports continue to be a focus area and enhancements to the standards are currently being developed that will provide additional support to border control. These enhancements will provide electronic access to additional data, including travel entry and exit stamps, electronic visas and additional biometrics on passport chips. Data integrity and authenticity will be supported using X.509 PKI. Read and write permissions will be managed through an ISO 7816-based PKI authorization infrastructure.
We’ll be covering of PKI in government in more detail in a future blog in our Evolution of PKI series. Meanwhile our next blog will take a closer look at the role of PKI in Authentication.
Public Key Infrastructure (PKI) facilitates security services across a global community of users and across various applications. As such, standards are a key requirement for the success of PKI. Without standards for PKI data structures, trust management and interoperability, the use of PKI would be severely limited and may never have experienced the success it has over the past 20-25 years.
Public Key Infrastructure (PKI) standards have evolved significantly over the past 25+ years. The initial standard was a relatively simple one, defined as a common base to support multiple applications. As individual applications and user communities adopted PKI technology, they fed additional requirements into the standards bodies, resulting in a number of updates to that base standard. In addition, some applications that have specific unique requirements have developed their own standards or standard profiles for use in their specific application. The ICAO electronic passport standard is one recent example.
What’s in a Standard?
All PKI standards created over these years cover at least the following main subjects:
• Certificate content and format
• Certificate revocation
• Trust models
All public-key certificates contain at least a public-key, identification of the subject/holder of that key, identification of the Certification Authority (CA) that issued the certificate and time period during which the certificate can be used. All certificates are digitally signed by the issuing Certification Authority (CA). Some certificates are issued to end-entities, such as human users or devices. Other certificates are issued to CAs, enabling certification paths to be constructed between a locally trusted CA and the remote CA that issued the certificate of interest.
Certificate revocation is a mechanism to shorten the validity period after a certificate has been issued. If, for example, an employee leaves the company, or the corresponding private key is compromised, the CA will likely want to revoke the corresponding certificate for the remainder of the published validity period. In some environments, rather than perform certificate revocation, CAs issue only certificates with very short initial validity periods, eliminating the need to revoke them.
PKI standards support a number of trust models including hierarchical, distributed, bridge etc. The appropriate trust model depends largely on the application in which PKI is being deployed or the community of users that will be taking part.
X.509 – The Base Standard for PKI
The initial “base standard” for PKI, developed jointly by the International Telecommunication Union (ITU) and International Organization for Standardization (ISO) was published in 1988. This standard, commonly referred to by its ITU identifier “X.509” (ISO identifier is 9594-8) defined a simple format for public-key certificates that enabled them to be distributed widely and enabled users to verify their authenticity and integrity. The certificates, digitally signed by the issuing Certification Authority (CA) contain a public-key, the identity of the key holder and the validity period of the certificate. The CA also regularly publishes a digitally signed Certificate Revocation List (CRL) identifying certificates that had to be revoked prior to the end of their validity period. As certificates can be issued to CAs as well as end-entities, certification paths can be constructed and any of the trust models supported. The original driver for this standard was the ITU-T X.400 secure messaging standard. However the base standard was defined to support any application, not just the X.400 requirements.
Establishing Trust Among User Communities
In the 1990s, as more communities of users began to adopt PKI, and the requirement to establish trust among user communities emerged, a number of requirements for enhancement to the base X.509 standard were identified. The U.S. Federal Government, for example, established a PKI infrastructure to connect the various government departments together and to bridge that integrated infrastructure with external PKI user communities. Trust needed to be manageable and constraints to control the boundaries of the interconnected user community needed to be possible. A set of extensions was added in the 3rd edition of X.509 (1997). Certificate extensions included constraints on the use of the public-key, constraints on the certification paths that could be constructed, alternative names associated with the certificate issuer and the certificate subject, link from the certificate to the appropriate CRL etc. CRL extensions included the ability to partition the set of revoked certificates across a set of smaller CRLs, identification of the set of certificates covered by a specific CRL, ability to issue interim delta CRLs and the ability to identify a CRL issuer other than the CA that issued the certificates. This milestone was the only time that the actual certificate and CRL structures were modified. Because of the addition of an optional field for the extensions, the versions were updated to version 3 certificates and version 2 CRLs. The extension mechanism is flexible and enables new features to be added to certificates and CRLs in a backward compatible way. Although there have been several updates to the X.509 standard the versions for certificate and CRL formats remain the same today. This consistency in versions is critical to interoperability and any future enhancements to the standards must also be done within the framework of existing versions.
The Internet PKI
Although the X.509 standard can be used in various applications, it makes no statement about which features/extensions should be mandatory or optional. The Internet Engineering Task Force (IETF) saw the need for specific interoperability profiles tailored for Internet applications. The IETF profile for “The Internet PKI” has, in fact, become adopted globally as the de facto base profile for certificates and CRLs far beyond its original intent. One reason for this is likely it is a general purpose profile intended to support generic Internet applications and at least provides some guidance on mandatory requirements, while not being over-restrictive or application-specific. Another contribution reason may be that IETF RFCs are available free over the Internet while the current version of the X.509 standard must be purchased. This IETF specification has itself undergone 2 revisions. The current specification is RFC 5280 published in 2008. Previous versions were RFC 2459 published in 1999, and RFC 3280 published in 2002. The IETF also defined some application-specific profiles for Internet applications such as secure messaging (S/MIME) and Transport Layer Security (TLS) supporting the authentication of websites. RFCs were also defined for PKI operational protocols including certificate management protocols, as well as Online Certificate Status Protocol (OCSP), an alternative to CRLs for revocation status checking.
Passports & Smartcards
Other standards groups and industry forums have developed specifications for their own environments. Generally these specifications tend to be based on the X.509 base standard as well as the IETF profiles and additional protocols. One example is the International Civil Aviation Authority (ICAO) and its specifications for electronic passports. In that application, a digitally signed copy of data about the document, the document issuer and the document holder is stored on a contactless IC within the passport. The associated certificates and CRLs are made available to border control so the digital signature can be verified and the data validated. For border control, this makes uncovering impersonation more reliable and identification of fraudulent documents easier. The PKI supporting this ICAO application is quite simple. Each country operates a single CA and that CA signs certificates for Document Signers that sign the passport data. There are no intermediate CAs, eliminating the need for most certificate extensions and simplifying the validation process significantly.
In addition to the base X.509 certificate format, some different formats have been defined to satisfy specific requirements where X.509 isn’t the best fit. One example is the ISO 7816 card-verifiable certificate format. This format better suits environments where certificates will be processed on chips in smart cards, passports etc. These certificates tend to be smaller than X.509 certificates, have shorter validity periods and have no revocation scheme. One application where this certificate format is being used is the authorization of access rights to sensitive fingerprint biometrics on travel documents within the European Union. Because certificate validation is done on the passport chip, their existing ISO 7816 file system and library can be re-used and additional X.509 validation library is not required. Given that these chips have much more restrictive processing capabilities than a computer typically used for validation in an X.509 PKI environment, use of the ISO 7816 PKI rather than X.509 is critical.
With terrorism a high priority for governments globally, secure passports continue to be a focus area and enhancements to the standards are currently being developed that will provide additional support to border control. These enhancements will provide electronic access to additional data, including travel entry and exit stamps, electronic visas and additional biometrics on passport chips. Data integrity and authenticity will be supported using X.509 PKI. Read and write permissions will be managed through an ISO 7816-based PKI authorization infrastructure.
We’ll be covering of PKI in government in more detail in a future blog in our Evolution of PKI series. Meanwhile our next blog will take a closer look at the role of PKI in Authentication.
