CA/B Forum Baseline Requirements

This page documents how kipuka enforces the CA/Browser Forum Baseline Requirements (BR) for the issuance and management of publicly-trusted TLS server certificates. Operators issuing certificates under a publicly-trusted root must configure kipuka to comply with these requirements; operators running private PKI may relax some constraints through configuration.

Certificate Profile Enforcement

kipuka validates every CSR against the BR certificate profile before signing. A CSR that violates any of the following rules is rejected with an EnrollReject audit event and an HTTP 400 response describing the violation.

Subject Fields

Key Type Requirements

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

Serial Number Generation

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

kipuka generates 160-bit (20-byte) serial numbers, significantly exceeding the minimum. The generation path depends on configuration:

Serial numbers are encoded as unsigned integers in the serialNumber field of the TBSCertificate, with the high bit set to zero to ensure a positive ASN.1 INTEGER encoding (per RFC 5280 section 4.1.2.2).

Extension Enforcement

kipuka enforces the following extensions on every issued certificate. Extensions not listed here may be added via CSR attributes or label configuration but are not required by the BR.

Mandatory Extensions

Extension Validation Rules

• If the CSR contains a basicConstraints extension with CA:TRUE, kipuka rejects the request. CA certificates are issued through the admin API, not through EST enrollment.

• If the CSR’s Key Usage includes keyCertSign or cRLSign, the request is rejected.

• SAN entries are validated for syntactic correctness: DNS names must be valid hostnames (no wildcards unless explicitly enabled), IP addresses must parse as IPv4 or IPv6, and email addresses must contain exactly one @.

Validity Period Enforcement

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

BR Validity Timeline

Configuration

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

[[est.label]]
name = "short-lived"
ca_id = "public-ca"
max_validity_days = 47

The effective maximum validity for a certificate is the minimum of:

1. The CA’s max_validity_days
2. The label’s max_validity_days (if set)
3. The client’s requested validity (if the CSR includes a ValidityPeriod attribute)

If the client’s requested validity exceeds the effective maximum, kipuka clamps the notAfter date to the allowed maximum rather than rejecting the request. This behavior is logged as an audit event with the original and clamped values.

STAR Integration

For STAR (RFC 8739) auto-renewal certificates, the validity period is typically much shorter than the BR maximum – often hours or days. STAR renewal orders track their own validity interval independently of the label’s max_validity_days.

Server-Side Key Generation Compliance

The /serverkeygen endpoint generates a key pair on the server and returns the private key to the client. The BR imposes requirements on how this private key is protected in transit.

Key Generation

• Key pairs are generated using the same CSPRNG path as serial numbers (PKCS#11 C_GenerateKeyPair when an HSM is configured, Synta software otherwise).
• The generated key type and size must satisfy the same minimums as client-generated keys (RSA >= 2048, ECDSA P-256 or P-384).
• The private key exists in kipuka’s memory only for the duration of the request. It is not written to disk or database.

Key Transport

The private key is returned to the client in a PKCS#7 EnvelopedData structure:

The response is a multipart MIME message containing:

1. The signed certificate (application/pkcs7-mime; smime-type=certs-only)
2. The encrypted private key (application/pkcs8)

Implementation Location

kipuka_est::serverkeygen handles key generation, wrapping, and response construction.

Name Constraints and Encoding

Distinguished Name Encoding

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

Name Constraints

kipuka supports Name Constraints through CA configuration. When a CA certificate contains a Name Constraints extension, kipuka enforces those constraints at CSR validation time:

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

This enforcement happens before signing, so a constraint violation results in an EnrollReject audit event rather than an improperly-issued certificate.

Internationalized Domain Names

kipuka accepts internationalized domain names (IDN) in SAN dNSName entries only in their A-label (Punycode) form, per BR section 7.1.4.2. U-label (Unicode) forms are rejected at CSR validation.

Compliance Checklist

The following checklist summarizes BR compliance status for operators running kipuka under a publicly-trusted root.