DER (Distinguished Encoding Rules) certificate encoding

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.

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.

03 04 06 6e 5d c0

03 04 06 6e 5d e0 

03 81 04 06 6e 5d c0

23 09 
   03 03 00 6e 5d
   03 02 06 c0

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.

03 04 06 6e 5d c0

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-----

what it isn't

where it is

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.

Planet Larg welcomes idiots. If you are an idiot and yet you cannot follow these instructions, please inform the technical staff (that's me - I'm Larg) that these opaque explanations may as well be in Swahili.

Lost? Start at the homepage. The PlanetLarg web site is hosted by Bayhosting.co.uk.

Larg's Internet Cluster Howto is licensed under a Creative Commons Attribution 3.0 Unported License. You are free to copy it and remix it, if you big me up. Click on the icon for more information.

disclaimer: Any deletion of crucial documents or other action which leads to dismissal caused by adherance to the instructions in this document are the sole responsibility of the reader. No responsibility, real, implied, indirect or upside down, is accepted by the author.