X.509 policies

Build with -Pkeeper.features=x509 -Pkeeper.platforms=ecc. The x509.tbs-certificate intent reads a DER-encoded RFC 5280 TBSCertificate from artifact.der64 (Base64).

authority "test:x509/service-leaf" {
    intent = "x509.tbs-certificate"
    version = "1.0.0"
    title = "Service leaf certificate"

    policy "test-x509-service-leaf" {
        allow "allow-service-leaf" when {
            version == 3
            subject.commonName == "api.svc.test"
            extensions.basicConstraints.present
            not extensions.basicConstraints.cA
            extensions.keyUsage.digitalSignature
            extensions.extKeyUsage.serverAuth
        }
    }
}

The example permits a non-CA service certificate for one common name with digital-signature and server-auth usage. Replace the name and attach it to the intended issuer key. Use Edict approval rules when issuance requires review.

Roots include encodedDerHex, encodedSha256, version, serialNumber, signature, issuer, subject, validity, subjectPublicKeyInfo, unique ids and extensions. serialNumber is a record, with numeric value and text decimal/hex representations. The current Keeper schema exposes selected name and extension fields. Validity timestamps are text, without duration-comparison helpers.

The CA service must authenticate enrollment and authorize control of the requested names. It must verify possession of the subject key, then allocate a serial and enforce the validity and certificate profile requirements. The CA must assemble and publish the certificate using the exact TBS bytes approved by Keeper. Relying parties still validate the completed certificate chain.

See Authorities for OCI publication and Edict for syntax.