Let's Encrypt Website Documentation

An OBJECT IDENTIFIER (OID) is a globally unique, hierarchical identifier composed of a sequence of integers. They are used to identify standards, algorithms, certificate extensions, organizations, or policies.

OIDs are organized in an "OID arc" (a hierarchy). For example:

• 1.2.840.113549 identifies RSA Security LLC.
• 2.5.4.6 identifies countryName.
• 2.5.4.10 identifies organizationName.

In specifications, OIDs are often represented using human-readable names via concatenation. For example, an OID can be defined by referencing a parent arc and adding new components:

   pkcs-1    OBJECT IDENTIFIER ::= {
       iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1
   }
   ...
   sha256WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 11 }

OCSP (Online Certificate Status Protocol) stapling is an optimization for checking certificate revocation status.

In traditional OCSP, the client (browser) must contact the Certificate Authority (CA) directly to verify a certificate. This introduces:

• Privacy Risks: The CA can track which users are visiting which sites.
• Performance Latency: Browsers must establish a separate connection to the CA before loading the web page.
• Resource Strain: High-traffic sites can overwhelm the CA's OCSP responder.

OCSP Stapling solves this by having the certificate holder (the web server) query the OCSP responder at regular intervals and cache the signed, time-stamped response. The server then "staples" this response to the initial TLS handshake. This eliminates the need for the client to contact the CA, improving privacy and speed.

Sunlight is a new implementation of a Certificate Transparency (CT) log designed for scalability, ease of operation, and reduced cost. Unlike traditional CT log architectures (like 'Oak') that rely on large relational databases, Sunlight uses a tile-based approach for its read path and a simplified single-node architecture for its write path.

Key improvements include:

• Scalable Read Path: Uses static 'tiles' instead of dynamic API endpoints, allowing logs to be served via cloud object storage (like S3) and CDNs.
• Simplified Write Path: Replaces complex leader election systems (like etcd) with a single-node writer using a compare-and-swap mechanism for checkpoints.
• Elimination of Merge Delay: Holds submissions to batch and integrate certificates immediately, avoiding the risks associated with the traditional 'Maximum Merge Delay' promise.

ASN.1 (Abstract Syntax Notation One) is a language used to define data structures and file formats in a language-independent way. It is used to define the contents of HTTPS certificates (following RFC 5280).

Unlike language-specific definitions (like C struct or Go type), ASN.1 allows different machines using different CPUs or operating systems to communicate by providing a standard way to define types and serialize them into bytes. A collection of ASN.1 definitions is referred to as a "module."

Point ::= SEQUENCE {
  x INTEGER,
  y INTEGER,
  label UTF8String
}

ASN.1 defines how in-memory data structures are turned into a series of bytes (serialization).

• DER (Distinguished Encoding Rules): A canonical serialization format. It is a variant of BER (Basic Encoding Rules) that adds rules to ensure a unique, deterministic encoding. For example, members in a SET OF must be sorted for DER.
• PEM (Privacy Enhanced Mail): A format often used to wrap DER-encoded certificates. It uses Base64 to encode the arbitrary bytes into alphanumeric characters and adds header/footer separators like -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----. PEM is primarily used for ease of copy-pasting.

In ASN.1, BIT STRING and OCTET STRING are used to hold arbitrary bits or bytes. They are ideal for unstructured data such as nonces or hash function outputs. They can also function similarly to a void pointer in C or an interface{} in Go, allowing you to hold data with a structure that is defined separately from the type system.

Example of a BIT STRING used for a certificate signature:

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signature            BIT STRING  }

Revocation allows a client to invalidate a certificate before its expiration date:

1. Signed Request: The client creates a revocation request and signs it using the account key pair authorized for the domain.
2. CA Verification: The Let's Encrypt CA verifies the authorization of the request.
3. CRL Publication: Upon successful verification, the CA publishes the revocation information via a Certificate Revocation List (CRL), allowing browsers and other relying parties to reject the certificate.

ASN.1 encoding instructions (like [5]) define how a field is wrapped.

• IMPLICIT: Encodes the field using the underlying type, but uses the tag number and class provided in the ASN.1 module. It uses fewer bytes.
• EXPLICIT: Encodes the field as the underlying type and then wraps it in an outer encoding layer that carries the tag number and class from the module. This sets the Constructed bit.

Defaults: If no keyword is present, the default is EXPLICIT, unless the module specifies EXPLICIT TAGS, IMPLICIT TAGS, or AUTOMATIC TAGS at the top.

# IMPLICIT example
[5] IMPLICIT UTF8String
# Encodes "hi" as: 85 02 68 69

# EXPLICIT example
[5] EXPLICIT UTF8String
# Encodes "hi" as: A5 04 0C 02 68 69