X.509
In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates.
A certificate contains an identity (a hostname, or an organization, or an individual) and a public key (RSA, DSA, ECDSA, ed25519, etc.
The first tasks of it was providing users with secure access to information resources and avoiding a cryptographic man-in-the-middle attack.
This contrasts with web of trust models, like PGP, where anyone (not just special CAs) may sign and thus attest to the validity of others' key certificates.
[2] It can be used in a peer-to-peer, OpenPGP-like web of trust,[citation needed] but was rarely used that way as of 2004[update].
for state identity information sharing treaty fulfillment purposes, and the IETF's Public-Key Infrastructure (X.509) (PKIX) working group has adapted the standard to the more flexible organization of the Internet.
[4] An early issue with Public Key Infrastructure (PKI) and X.509 certificates was the well known "which directory" problem.
The problem is the client does not know where to fetch missing intermediate certificates because the global X.500 directory never materialized.
The CSR may be accompanied by other credentials or proofs of identity required by the certificate authority.
An organization's trusted root certificates can be distributed to all employees so that they can use the company PKI system.
For example, Firefox provides a CSV and/or HTML file containing a list of Included CAs.
[9] The structure foreseen by the standards is expressed in a formal language, Abstract Syntax Notation One (ASN.1).
The inner format of issuer and subject unique identifiers specified in X.520 The Directory: Selected attribute types recommendation.
An example of reuse will be when a CA goes bankrupt and its name is deleted from the country's public list.
A CA can use extensions to issue a certificate only for a specific purpose (e.g. only for signing digital objects).
In all versions, the serial number must be unique for each certificate issued by a specific CA (as mentioned in RFC 5280).
There is no single OID to indicate extended validation, which complicates user agent programming.
Other PKIs, like the Internet's PKI (PKIX), do not place any special emphasis on extended validation.
During the race to the bottom CA's cut prices to lure consumers to purchase their certificates.
As a result, profits were reduced and CA's dropped the level of validation they were performing to the point there were nearly no assurances on a certificate.
Since the certificate is needed to verify signed data, it is possible to include them in the SignedData structure.
The description in the preceding paragraph is a simplified view on the certification path validation process as defined by RFC 5280 section 6, which involves additional checks, such as verifying validity dates on certificates, looking up CRLs, etc.
There are a number of publications about PKI problems by Bruce Schneier, Peter Gutmann and other security experts.
Some problems are: Digital signature systems depend on secure cryptographic hash functions to work.
Exploiting a hash collision to forge X.509 signatures requires that the attacker be able to predict the data that the certificate authority will sign.
This can be somewhat mitigated by the CA generating a random component in the certificates it signs, typically the serial number.
[40] In 1995, the Internet Engineering Task Force in conjunction with the National Institute of Standards and Technology[45] formed the Public-Key Infrastructure (X.509) working group.
TLS/SSL and HTTPS use the RFC 5280 profile of X.509, as do S/MIME (Secure Multipurpose Internet Mail Extensions) and the EAP-TLS method for WiFi authentication.
The Microsoft Authenticode code signing system uses X.509 to identify authors of computer programs.
However, the popular OpenSSH implementation does support a CA-signed identity model based on its own non-X.509 certificate format.
