NIAP CA Protection Profile

This page maps kipuka capabilities to the Security Functional Requirements (SFRs) defined in the NIAP Certificate Authority Protection Profile v2.0. The mapping is intended for evaluation teams preparing a Common Criteria assessment and for operators who need to verify that their deployment satisfies the Protection Profile.

Note: A Common Criteria evaluation requires an accredited evaluation facility. This document describes how kipuka addresses each SFR at the implementation level; it does not constitute a certified Security Target.

Audit (FAU)

FAU_GEN.1 – Audit Data Generation

Requirement: The TOE shall generate an audit record for each auditable event, including the date/time, event type, subject identity, and outcome.

How kipuka satisfies it:

The kipuka::audit module records structured audit events through the AuditEvent struct. Every event includes:

• Timestamp (UTC, microsecond precision)
• Event type (AuditEventType enum)
• Subject identity (client certificate DN, OTP identifier, or GSSAPI principal)
• Outcome (success or failure with reason)
• Source IP address and EST label

The following event types are audited:

Implementation location: kipuka::audit::record() is called from every EST handler and authentication layer.

Evaluation notes: The event set covers all “minimum audit events” listed in Table 5 of the Protection Profile. Additional events (OTP lifecycle, HA health changes) exceed the minimum.

FAU_GEN.2 – User Identity Association

Requirement: The TOE shall associate each auditable event with the identity of the user that caused the event.

How kipuka satisfies it:

The AuditEvent struct contains a subject field populated from the authenticated identity:

• mTLS: Subject DN and serial number of the client certificate.
• OTP: The OTP identifier (opaque token ID, not the secret).
• GSSAPI: The Kerberos principal name.
• CMS: The signer DN from the CMS SignerInfo.
• Unauthenticated (/cacerts): Recorded as "anonymous" with the source IP.

FAU_STG.1 – Protected Audit Trail Storage

Requirement: The TOE shall protect the stored audit records from unauthorized deletion.

How kipuka satisfies it:

Audit records are written through two channels, both designed for append-only semantics:

1. Database – Audit records are INSERT-only. The database schema does not expose UPDATE or DELETE operations on the audit table. When using PostgreSQL, row-level security policies can further restrict modification.

2. File – When audit.file is configured, events are appended to a JSON Lines file. kipuka opens the file in append-only mode (O_APPEND). File-system permissions should restrict the audit file to the kipuka service account.

3. Syslog – When audit.syslog is configured, events are forwarded to a remote syslog server over TLS, placing the audit trail outside the TOE boundary.

Evaluation notes: The Protection Profile requires that “the TSF shall be able to prevent unauthorized deletion of the stored audit records.” Operators must ensure that file-system permissions and database RBAC are configured to prevent the kipuka process from deleting its own audit records. Shipping audit events to a remote syslog server (channel 3) provides the strongest protection.

Cryptographic Support (FCS)

FCS_CKM.1 – Cryptographic Key Generation

Requirement: The TOE shall generate asymmetric cryptographic keys in accordance with a specified key generation algorithm and key sizes.

How kipuka satisfies it:

Serial numbers are 160 bits (20 bytes) from a CSPRNG, exceeding the CA/B Forum minimum of 64 bits and the NIAP requirement for unpredictable serial numbers.

Implementation location: kipuka_hsm::key::HsmKeyPair for CA keys; kipuka_est::serverkeygen for end-entity keys generated via /serverkeygen.

FCS_CKM.2 – Cryptographic Key Distribution

Requirement: The TOE shall distribute cryptographic keys in accordance with a specified key distribution method.

How kipuka satisfies it:

• CA certificate distribution – The /cacerts endpoint returns the CA certificate chain as a PKCS#7 certs-only message. Distribution is over TLS (FCS_TLSS_EXT.1).

• Server-generated key distribution – When /serverkeygen is enabled, the generated private key is encrypted to the client using PKCS#7 EnvelopedData:

  • AES-256 key wrapping with the content-encryption key wrapped to the client’s public key via RSA-OAEP or ECDH-ES.
  • The wrapped key and signed certificate are returned as a single multipart MIME response.

Implementation location: kipuka_est::serverkeygen for key wrapping; kipuka_est::cacerts for CA chain distribution.

FCS_COP.1 – Cryptographic Operation

Requirement: The TOE shall perform cryptographic operations in accordance with specified algorithms and key sizes.

How kipuka satisfies it:

Implementation location: kipuka_hsm::sign dispatches to sign_rsa_pkcs1, sign_rsa_pss, sign_ecdsa, or sign_ml_dsa depending on the CA key type.

FCS_RBG_EXT.1 – Random Bit Generation

Requirement: The TOE shall use a DRBG that is seeded by an entropy source.

How kipuka satisfies it:

• With HSM: Random bytes are obtained via PKCS#11 C_GenerateRandom, which invokes the HSM’s FIPS-validated DRBG.
• Without HSM: Random bytes are obtained from the operating system’s CSPRNG via getrandom(2) on Linux or the equivalent on other platforms.

Serial number generation always uses whichever RBG is active.

FCS_TLSS_EXT.1 – TLS Server

Requirement: The TOE shall implement TLS 1.2 and/or TLS 1.3 as a server.

How kipuka satisfies it:

kipuka uses rustls for TLS termination.

Implementation location: kipuka::tls module configures rustls::ServerConfig.

Identification and Authentication (FIA)

FIA_AFL.1 – Authentication Failure Handling

Requirement: The TOE shall detect when a configurable number of unsuccessful authentication attempts occur and take action.

How kipuka satisfies it:

The OTP authentication subsystem implements rate limiting and lockout:

When the threshold is reached:

1. An AuthFailure audit event is recorded with reason "lockout".
2. Subsequent authentication attempts for that OTP identifier return HTTP 403 until the lockout expires.
3. If the lockout is triggered by mTLS (invalid client cert), the TLS handshake fails before the HTTP layer is reached; the audit event records the client IP and certificate serial number.

Implementation location: kipuka::auth::otp for OTP lockout; kipuka::auth::mtls for mTLS failure logging.

FIA_UAU.1 – Timing of Authentication

Requirement: The TOE shall allow only the retrieval of CA certificates before the user is authenticated.

How kipuka satisfies it:

• /cacerts – Unauthenticated. No client credential is required.
• All other endpoints (/simpleenroll, /simplereenroll, /fullcmc, /serverkeygen, /csrattrs) – Require authentication via at least one configured method (mTLS, OTP, GSSAPI, or CMS signature).

The EstAuth extractor in kipuka::auth enforces this policy. The OptionalAuth extractor is used only for /cacerts and returns AuthMethod::None when no credential is presented.

Implementation location: kipuka::auth::EstAuth and kipuka::auth::OptionalAuth.

FIA_UAU.5 – Multiple Authentication Mechanisms

Requirement: The TOE shall provide multiple authentication mechanisms.

How kipuka satisfies it:

kipuka supports five authentication methods, selectable per EST label:

Security Management (FMT)

FMT_SMR.1 – Security Roles

Requirement: The TOE shall maintain the roles of operator and user.

How kipuka satisfies it:

kipuka defines two distinct roles:

The admin API listens on a separate address and port (server.admin_listen, default 127.0.0.1:9443) with independent TLS configuration. No EST client credential grants access to the admin API, and no admin credential grants access to EST endpoints on behalf of a client.

Implementation location: kipuka::routes::admin for operator endpoints; kipuka::routes::est for user endpoints.

FMT_SMF.1 – Management Functions

Requirement: The TOE shall provide management functions for authorized operators.

How kipuka satisfies it:

The admin API provides:

Trusted Path (FTP)

FTP_TRP.1 – Trusted Path

Requirement: The TOE shall provide a communication path between itself and remote users that is logically distinct from other paths and provides assured identification of its endpoints.

How kipuka satisfies it:

• EST over TLS – All enrollment communication uses TLS with server certificate authentication and (for authenticated endpoints) mutual TLS. The server certificate identifies the kipuka instance; the client certificate identifies the enrolling device.

• Admin on separate TLS – The admin API uses an independent TLS listener with its own certificate and trust anchors. This provides logical separation between the user-facing EST path and the operator-facing management path.

• DTLS for CoAP – CoAP enrollment uses DTLS 1.2 for the trusted path, providing the same endpoint authentication guarantees over UDP.

Implementation location: kipuka::tls for EST and admin TLS; kipuka_coap::dtls for DTLS.

SFR Coverage Summary