CA/B Forum Baseline Requirements

This page documents compliance with the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.2.8 (16-Jun-2026). Operators issuing certificates under a publicly-trusted root must configure kipuka and the issuing CA to satisfy these requirements jointly; operators running private PKI may relax constraints through configuration.

Responsibility Boundary

kipuka is a Registration Authority (RA) and enrollment server. It validates CSRs and enforces certificate profile constraints, but it does not perform domain validation, CAA checking, or revocation services. Those responsibilities belong to the issuing Certification Authority.

The following table maps each BR area to the specific software component that owns it. When deploying under a publicly-trusted root, all affected components must be configured correctly.

kipuka (RA) Responsibilities

Issuing CA (Dogtag PKI) Responsibilities

Certificate Profile Enforcement

kipuka validates every CSR against the BR certificate profile before forwarding to the CA for signing. A CSR that violates any rule is rejected with an EnrollReject audit event and an HTTP 400 response.

Subject Fields

Key Type and Size Requirements (§6.1.5)

To restrict a label to specific key types:

[[est.label]]
name = "web-servers"
ca_id = "issuing-ca-1"
allowed_key_types = ["rsa-3072", "rsa-4096", "ecdsa-p256", "ecdsa-p384"]

Public Key Quality Checks (§6.1.6)

Weak Key Rejection (§6.1.1.3)

The BR requires CAs to reject keys known to be weak. kipuka does not currently perform weak key checks.

Serial Number Generation

The BR requires that certificate serial numbers contain at least 64 bits of output from a CSPRNG (§7.1).

kipuka generates 160-bit (20-byte) serial numbers, significantly exceeding the minimum. Serial numbers must be non-sequential, greater than zero, and less than 2^159.

Serial numbers are encoded as unsigned integers with the high bit set to zero to ensure a positive ASN.1 INTEGER encoding (per RFC 5280 §4.1.2.2).

Extension Enforcement

Mandatory Extensions (§7.1.2.7.6)

Notes:

• AIA MUST contain at least one AccessDescription. The id-ad-caIssuers method (SHOULD) provides a URL to the issuing CA’s certificate. When using Dogtag, this is set in the certificate profile.
• CRL Distribution Points presence depends on whether the certificate includes an AIA OCSP pointer and the certificate’s validity period (§7.1.2.11.2).
• Certificate Policies MUST include a Reserved Certificate Policy Identifier matching the validation type: DV (2.23.140.1.2.1), IV (2.23.140.1.2.3), OV (2.23.140.1.2.2), or EV (2.23.140.1.1). kipuka does not enforce the correct OID per validation type.

Extension Validation Rules

• CSRs with basicConstraints CA:TRUE are rejected.
• CSRs with Key Usage keyCertSign or cRLSign are rejected.
• pathLenConstraint MUST NOT be present in subscriber certificates (§7.1.2.7.8). kipuka does not include it, but does not actively reject CSRs that request it.
• SAN entries are validated: DNS names must be valid hostnames (no wildcards unless enabled), IP addresses must parse as IPv4/IPv6, email addresses must contain exactly one @.
• notBefore MUST be within 48 hours of the certificate signing operation (§7.1.2.7). kipuka does not enforce this constraint.

Subscriber Certificate Key Usage (§7.1.2.7.11)

For RSA keys, digitalSignature SHOULD be set. keyEncipherment MAY be set for TLS 1.2 compatibility. dataEncipherment is a Pending Prohibition.

For ECC keys, digitalSignature MUST be set. keyAgreement is a Pending Prohibition.

kipuka defaults: digitalSignature, keyEncipherment for RSA, digitalSignature for ECDSA. Configurable via ca.default_key_usage.

Subscriber Certificate EKU (§7.1.2.7.10)

Validity Period Enforcement (§6.3.2)

The CA/B Forum is reducing maximum certificate validity on a declining timeline. kipuka tracks this through the max_validity_days parameter.

For the purpose of these calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, represents an additional day. Certificates SHOULD NOT be issued for the maximum permissible time by default, to account for clock drift.

Each CA and each EST label can specify a maximum validity:

[[ca]]
id = "public-ca"
name = "Public TLS CA"
cert = "/etc/kipuka/ca/public-ca.pem"
key = "/etc/kipuka/ca/public-ca.key"
validity_days = 90
max_validity_days = 200

The effective maximum is the minimum of the CA’s max_validity_days, the label’s max_validity_days, and the client’s requested validity. If the client requests more, kipuka clamps notAfter to the allowed maximum and logs the original and clamped values.

STAR Integration

STAR (RFC 8739) auto-renewal certificates typically use much shorter validity periods (hours or days). STAR renewal orders track their own interval independently of max_validity_days.

Domain Validation

kipuka does not perform domain validation. This is a CA responsibility. When using Dogtag as the issuing CA, the ACME subsystem provides HTTP-01 and DNS-01 challenge validation.

Validation Data Reuse (§4.2.1)

Domain and IP address validation data has maximum reuse periods that decline over time:

Prohibited Names (§4.2.2)

CAs SHALL NOT issue certificates containing Internal Names or Reserved IP Addresses. Effective 2026-03-15, certificates SHALL NOT contain Domain Names ending in an IP Reverse Zone Suffix.

CAA Record Processing (§4.2.2.1)

Status: CA Responsibility – not implemented in Dogtag.

The CA MUST retrieve and process CAA records in accordance with RFC 8659 for each dNSName in the subjectAltName extension before certificate issuance. The CA MUST process the issue, issuewild, and iodef property tags.

Impact: Neither kipuka nor Dogtag currently implements CAA checking. Any deployment under a publicly-trusted root must add CAA processing upstream or implement it in the CA before issuance.

Multi-Perspective Issuance Corroboration (§3.2.2.9)

Status: CA Responsibility – not implemented in Dogtag.

The CA MUST corroborate domain validation and CAA checks from multiple remote Network Perspectives before certificate issuance.

Quorum table (Table 5 of the BR):

Impact: This requirement is already in effect. Deployments under publicly-trusted roots cannot issue certificates without MPIC infrastructure.

Certificate Transparency (§4.3.1.2, §7.1.2.9)

Status: CA Responsibility – available in Dogtag.

When using Dogtag with CT enabled, the CA creates a precertificate with the poison extension (OID 1.3.6.1.4.1.11129.2.4.3), submits it to configured CT logs, and replaces the poison with an SCT list extension (OID 1.3.6.1.4.1.11129.2.4.2) in the final certificate. kipuka receives the final certificate with embedded SCTs and returns it to the client.

Certificate Linting (§4.3.1.2)

Status: Not Implemented in either component.

Effective 2025-03-15, the CA SHALL implement a Linting process to test the technical conformity of each to-be-signed certificate artifact prior to signing. CAs SHOULD use widely-adopted Linting tools (see cabforum.org/resources/tools).

Linting could be split across the stack: kipuka could lint the CSR and proposed certificate content pre-submission, while the CA lints the to-be-signed tbsCertificate post-assembly. Neither integration exists today.

Revocation and OCSP

Revocation Requirements (§4.9)

Status: CA Responsibility.

CRL Requirements (§4.9.7)

OCSP Requirements (§4.9.9)

SHA-1 Sunset (§7.1.3.2)

Status: Not Enforced.

kipuka should reject enrollment requests that specify SHA-1 as the signature algorithm. This check is not currently implemented.

Server-Side Key Generation (§6.1.2)

The /serverkeygen endpoint generates a key pair and returns the private key to the client in a PKCS#7 EnvelopedData structure.

Additional BR constraints:

• If the subscriber certificate will contain id-kp-serverAuth, the CA SHALL NOT generate a key pair on behalf of the subscriber and SHALL NOT accept a certificate request using a key pair previously generated by the CA (§6.1.1.3). kipuka does not enforce this cross-request check.
• Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization (§6.1.2).
• Key pairs are generated using the same CSPRNG path as serial numbers and exist in kipuka’s memory only for the duration of the request.

Name Constraints and Encoding

Distinguished Name Encoding (§7.1.4)

All Distinguished Name components are encoded as UTF8String per RFC 5280 §4.1.2.4 and BR §7.1.4. kipuka does not use PrintableString or TeletexString encoding.

Name Constraints

kipuka enforces Name Constraints from the CA certificate at CSR validation time:

• Permitted subtrees – SAN DNS names must fall within permitted DNS subtrees. IP addresses must fall within permitted IP ranges.
• Excluded subtrees – SAN entries matching excluded subtrees cause rejection.

Enforcement before signing means a constraint violation produces an EnrollReject audit event rather than a mis-issued certificate.

Internationalized Domain Names (§7.1.4.2)

kipuka accepts IDN in SAN dNSName entries only in A-label (Punycode) form. U-label (Unicode) forms are rejected at CSR validation.

Compliance Timeline

Operators deploying kipuka under a publicly-trusted root should track these upcoming BR deadlines:

Compliance Checklist

kipuka Enforcement

Dogtag CA Enforcement