introduction
An X.509 certificate is a type of public key certificate. It contains a public key and a few bits of information about the key. It is basically a list of attributes and values, like any data store. There are a few different certificate file formats used to store an X.509 certificate. It is usually written down in a machine-friendly format called DER.
An X.509 certificate starts its life as text that can be printed and read by real people. Text is not machine-friendly. Certificates are not meant to be used by people, they are meant for computers. The X.509 certificate was created decades ago when making code machine friendly was a big deal because of the huge expense of computer horsepower and network bandwidth. Anything that reduced whopping computer budgets was a sure-fire winner.
The ITU agency came up with layers of serious sounding acronyms for describing how computers can be linked together, collectively called OSI (Open Systems Interconnection). They wrote a language for describing any attribute and its values called ASN.1 (Abstract Syntax Notation One), a method of turning attributes and values into a machine-friendly format called BER (Basic Encoding Rules) and a simpler method of turning attributes and values into machine code called DER (Distinguished Encoding Rules). A DER file is a binary encoded copy of attributes and values.
A DER file is often translated into a PEM (Privacy-Enhanced Mail) file. PEM translation turns binary data into text characters, which is handy for sending in e-mails and copying and pasting.
what it is
To understand what is in a DER file, you need to suffer some acronym soup. The history of how the DER standard came about involves many years of committee standards.
For more more detail than you want on ASN.1, BER and DER, see ftp://ftp.rsasecurity.com/pub/pkcs/ascii/layman.asc.
OSI (Open Systems Interconnection)
One of the most complex systems today, and one that also involves a great deal of abstraction, is Open Systems Interconnection (OSI, described in X.200). OSI is an internationally standardized architecture that governs the interconnection of computers from the physical layer up to the user application layer. Objects at higher layers are abstracts built with things from the lower layers.
ASN.1 (Abstract Syntax Notation One)
The OSI's language for specifying abstract objects is called ASN.1 (Abstract Syntax Notation One, defined in X.208). ASN.1 is a meta language that looks like this.
| LIC table: an ASN.1 data type used to represent certificates |
|---|
Certificate ::= SIGNED { SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- if present, version shall be v2 or v3
subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- if present, version shall be v2 or v3
extensions [3] Extensions OPTIONAL
-- If present, version shall be v3 -- } }
Version ::= INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER
AlgorithmIdentifier ::= SEQUENCE {
algorithm ALGORITHM.&id ({SupportedAlgorithms}),
parameters ALGORITHM.&Type ({SupportedAlgorithms}{ @algorithm})
-- Definition of the following information object set is deferred, perhaps to standardized
-- profiles or to protocol implementation conformance statements.
The set is required
-- specify a table constraint on the parameters component of AlgorithmIdentifier.
-- SupportedAlgorithms ALGORITHM ::= { ...
}
Validity ::= SEQUENCE {
notBefore Time,
notAfter Time }
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }
Extensions ::= SEQUENCE OF Extension
Extension ::= SEQUENCE {
extnId EXTENSION.&id ({ExtensionSet}),
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
-- contains a DER encoding of a value of type &ExtnType
-- for the extension object identified by extnId -- }
ExtensionSet EXTENSION ::= { ...
}
|
BER (Basic Encoding Rules)
Once you have defined your abstract thing, you need to store it. Dumping this text to a file takes up a lot of space, and these standards were written decades ago when disk space was expensive. OSI came up with a much more machine friendly format called BER (Basic Encoding Rules, defined in X.209), a set of rules for representing ASN.1 objects as strings of ones and zeros. BER describes how to represent or encode values of each ASN.1 type as a string of eight-bit octets. BER is designed to be flexible. There is generally more than one way to BER-encode a given value.
| LIC table: BER encoding of the BIT STRING value "011011100101110111" | |
|---|---|
| BER octets | encoding type |
03 04 06 6e 5d c0 |
DER encoding |
03 04 06 6e 5d e0 |
padded with "100000" |
03 81 04 06 6e 5d c0 |
long form of length octets |
23 09 03 03 00 6e 5d 03 02 06 c0 |
constructed encoding: "0110111001011101" + "11" |
DER (Distinguished Encoding Rules)
A simpler set of rules were created called the Distinguished Encoding Rules (DER). DER is a subset of BER. It gives a unique encoding to each ASN.1 value.
Putting all this together for the attribute and value countryName = "US" , you get this sequence. CountryName is defined as an attribute type in the X.520 standard. The attribute definition of countryName is written in ASN.1 like this: countryName OBJECT IDENTIFIER ::= { attributeType 6 }. Encoding this attribute and the value US into DER format you end up with a load of unfriendly octets like this: 06 03 55 04 06 13 02 55 53.
| LIC table: DER encoding of the BIT STRING value "011011100101110111" | |
|---|---|
| DER octets | encoding type |
03 04 06 6e 5d c0 |
DER encoding |
PEM (Privacy-Enhanced Mail)
PEM is the draft Internet Privacy-Enhanced Mail standard, designed, proposed, but not yet officially adopted, by the Internet Activities Board to provide secure electronic mail over the Internet. Designed to work with RFC 822 e-mail formats, PEM includes encryption, authentication, and key management, and allows use of both public-key and secret-key cryptosystems. Multiple cryptographic tools are supported; for each mail message, the specific encryption algorithm, digital signature algorithm, hash function, and so on are specified in the header. PEM explicitly supports only a few cryptographic algorithms; others may be added later. DES ( see Question 64 ) in CBC mode is currently the only message encryption algorithm supported, and both RSA ( see Question 8 ) and DES are supported for key management. Public-key management in PEM is based on X.509 certificates ( see Question 165 ).
The details of PEM can be found in Internet RFCs 1421 through 1424 . PEM has been on the draft track for more than two years and it seems that the standard may be superseded by S/MIME and PEM-MIME.
A PEM file is a printable version of the DER file. It has a header and a footer, and is laid out a little like an HTTP reply or an e-mail: a couple of header lines written in plain text, a blank line and a message body (the private key) encoded in base 64. Don't rely on the file extension ".pem". MS Windows uses "*.cer".
-----BEGIN CERTIFICATE----- MIIEczCCA1ugAwIBAgIBADANBgkqhkiG9w0BAQQFAD..AkGA1UEBhMCR0Ix EzARBgNVBAgTClNvbWUtU3RhdGUxFDASBgNVBAoTC0..0EgTHRkMTcwNQYD VQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcn..XRpb24gQXV0aG9y aXR5MRQwEgYDVQQDEwtCZXN0IENBIEx0ZDAeFw0wMD..TUwMTZaFw0wMTAy MDQxOTUwMTZaMIGHMQswCQYDVQQGEwJHQjETMBEGA1..29tZS1TdGFW0ZTEU MBIGA1UEChMLQmVzdCBDQSBMdGQxNzA1BgNVBAsTLk..DEgUHVibGljIFBy aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxFD..AMTC0Jlc3QgQ0Eg THRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCg..Tz2mr7SZiAMfQyu vBjM9OiJjRazXBZ1BjP5CE/Wm/Rr500PRK+Lh9x5eJ../ANBE0sTK0ZsDGM ak2m1g7oruI3dY3VHqIxFTz0Ta1d+NAjwnLe4nOb7/..k05ShhBrJGBKKxb 8n104o/5p8HAsZPdzbFMIyNjJzBM2o5y5A13wiLitE..fyYkQzaxCw0Awzl kVHiIyCuaF4wj571pSzkv6sv+4IDMbT/XpCo8L6wTa..sh+etLD6FtTjYbb rvZ8RQM1tlKdoMHg2qxraAV++HNBYmNWs0duEdjUbJ..XI9TtnS4o1Ckj7P OfljiQIDAQABo4HnMIHkMLB0GA1UdDgQWBBQ8urMCRL..5AkIp9NJHJw5TCB tAYDVR0jBIGsMIGpgBQ8urMCRLYYMHUKU5AkIp9NJH..aSBijCBhzELMAkG A1UEBhMCR0IxEzARBgNVBAgTClNvbWUtU3RhdGUxFD..AoTC0Jlc3QgQ0Eg THRkMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcm..ENlcnRpZmljYXRp b24gQXV0aG9yaXR5MRQwEgYDVQQDEwtCZXN0IENBIE..DAMBgNVHRMEISP01AD AQH/MA0GCSqGSIb3DQEBBAUAA4IBAQC1uYBcsSncwA..DCsQer772C2ucpX xQUE/C0pWWm6gDkwd5D0DSMDJRqV/weoZ4wC6B73f5..bLhGYHaXJeSD6Kr XcoOwLdSaGmJYslLKZB3ZIDEp0wYTGhgteb6JFiTtn..sf2xdrYfPCiIB7g BMAV7Gzdc4VspS6ljrAhbiiawdBiQlQmsBeFz9JkF4..b3l8BoGN+qMa56Y It8una2gY4l2O//on88r5IWJlm1L0oA8e4fR2yrBHX..adsGeFKkyNrwGi/ 7vQMfXdGsRrXNGRGnX+vWDZ3/zWI0joDtCkNnqEpVn..HoX -----END CERTIFICATE-----
history
In the beginning (or 1976), Whitfield Diffie, Martin Hellman and Ralph Merkle published work on PKC (Public key Cryptography). Three guys named Ronald Rivest, Adi Shamir, and Leonard Adleman built upon their work and started the RSA company in 1982 to turn mathematics into flash cars and big houses. These clever mathematicians made high grade cryptography available to the masses.
The ITU (International Telecommunications Union), an agency of the United Nations, published the X.509 recommendation in 1988 which defined many things, including how to embed a public key and other information into a certificate. Netscape came up with the SSL protocol for exchanging certificates and setting up a secure WWW link. The SSL protocol defines cipher suites. The components were in place for giving birth to e-commerce.
In 1991 RSA and a bunch other companies got the e-commerce ball rolling by defining PKCS (Public Key Cryptography Standards) for using certificates: storing them, exchanging them, using them and so on.
In 1994 Netscape came up with the SSL protocol for exchanging certificates and setting up a secure WWW link. The SSL protocol defines cipher suites. They built it into their web browser, Netscape Navigator 1.1.
