Interoperability & Standards Compliance

Target Audience: Solution Architects, Compliance Officers, Integration Engineers

Reading Time: 15 minutes

Prerequisites: Understanding of cryptographic standards, regulatory frameworks

Executive Summary

ANKASecure achieves broad interoperability through adherence to industry standards (IETF JOSE, NIST PQC, OAuth 2.0) and support for legacy format conversion (PKCS#7). This document consolidates compliance claims and interoperability capabilities across cloud platforms, identity providers, and regulatory frameworks.

Table of Contents

1. Standards Overview
2. IETF Standards Compliance
3. NIST Standards & Post-Quantum Cryptography
4. Regulatory Framework Alignment
5. Cloud Platform Integration
6. Identity Federation
7. Import & Export Formats
8. API Interoperability
9. Compliance Matrix
10. External Standards Bodies

Standards Overview

ANKASecure implements standards-first architecture to ensure maximum interoperability:

IETF Standards Compliance

JOSE (JSON Object Signing and Encryption)

RFCs implemented:

Extensions beyond standards:

• Detached content mode for streaming (JWS JSON, JWE multipart)
• Post-quantum algorithms (ML-KEM, ML-DSA, FALCON, SLH-DSA)
• Composite algorithm identifiers (pairings corresponding to the IETF composite Internet-Drafts)

See: JOSE Technical Reference

OAuth 2.0 & OpenID Connect

Supported flows:

• Authorization Code Flow (OAuth 2.0)
• Client Credentials Flow (machine-to-machine)
• JWT Bearer Tokens (RFC 7523)

Token validation:

• Standard JWT claims: iss, aud, exp, nbf, iat, jti
• Custom claims: tenantId, scopes, appId
• Signature verification with public keys

Interoperability:

• Compatible with Auth0, Okta, Ping Identity, Azure AD, AWS Cognito
• Multi-issuer support for federated environments
• Standard token introspection (RFC 7662)

Legacy Format Support

PKCS#7 (CMS) Conversion:

• RFC 5652 (Cryptographic Message Syntax) parsing
• SignedData → JWS conversion
• EnvelopedData → JWE conversion
• SignedAndEnvelopedData → nested JWE(JWS)

See: PKCS#7 to JOSE Conversion

NIST Standards & Post-Quantum Cryptography

NIST FIPS Post-Quantum Standards

Implemented algorithms:

Additional PQC algorithms:

• FALCON: FALCON-512, FALCON-1024 (compact signatures)
• Composite keys: 41 combinations (classical + PQC)

NIST security levels:

See: Algorithms Catalog

NIST Publications — Alignment

These are alignment statements, self-assessed; NIST validates no product against them.

IETF Composite Keys

Implementation:

• Construction corresponding to draft-ietf-lamps-pq-composite-kem-21 (composite ML-KEM) and draft-ietf-lamps-pq-composite-sigs-19 (composite ML-DSA), both Internet-Drafts
• Mode: COMPOSITE_KEM_COMBINE, with the key's KDF token (HKDF-SHA256 by default, HKDF-SHA384, HKDF-SHA512, CatKDF, CasKDF)
• Security level matching (128-bit classical + 128-bit PQC, etc.)
• Single KID for composite key pairs

Composite algorithm examples:

• P-384+ML-KEM-768 (112-bit + 192-bit → 192-bit effective)
• P-256+ML-KEM-768 (128-bit + 192-bit → 192-bit effective)
• P-256+ML-DSA-65 (128-bit + 192-bit → 192-bit effective)

See: IETF Composite ML-KEM and Composite Signatures — Alignment

Regulatory Framework Alignment

CNSA 2.0 (NSA Commercial National Security Algorithm Suite)

Timeline:

• 2025: Begin transition to quantum-resistant algorithms
• 2030: Complete migration for National Security Systems
• 2033: Complete migration for all classified systems

ANKASecure readiness:

• ✅ ML-KEM-1024 and ML-DSA-87, the CNSA 2.0 public-key parameter sets, offered standalone and in composite keys
• ✅ Hybrid/composite keys (defense-in-depth)
• ✅ Zero-code migration (re-encrypt/re-sign APIs)
• ✅ Policy-driven algorithm selection

OWASP Top 10 Controls

ANKASecure security controls:

See: OWASP API Security Alignment

GDPR (General Data Protection Regulation)

Compliance features:

• Data sovereignty: Tenant-isolated keystores, configurable geographic deployment
• Right to erasure: Key deletion APIs, secure key archival
• Data portability: Export APIs (JWK format for public keys)
• Encryption at rest: AES-256-GCM, configurable algorithms
• Audit trail: Comprehensive logging, tamper-evident records

HIPAA (Health Insurance Portability and Accountability Act)

Technical safeguards:

• Access controls: Role-based access (RBAC), authentication, authorization
• Audit controls: Comprehensive logging, immutable audit trails
• Integrity controls: Digital signatures, hash verification
• Transmission security: TLS 1.3, PQC handshake, end-to-end encryption

PCI-DSS (Payment Card Industry Data Security Standard)

Key management requirements:

• Requirement 3: Protect stored cardholder data (AES-256-GCM encryption)
• Requirement 4: Encrypt cardholder data during transmission (TLS 1.2 and 1.3 at the edge, TLS 1.3 to the data stores, optional PQC session encryption)
• Requirement 8: Identify and authenticate access (JWT, PBKDF2-HMAC-SHA256 password storage, account lockout, TOTP enrollment)
• Requirement 10: Track and monitor access (audit logs, anomaly detection)

SOC 2 Type II

Trust Service Criteria:

• Security: Multi-tenant isolation, HSM integration, FIPS-approved algorithms (module validation only through a customer's validated HSM)
• Availability: High-availability deployment, disaster recovery
• Processing Integrity: Input validation, integrity checks, digital signatures
• Confidentiality: Encryption at rest/transit, key rotation, access controls
• Privacy: Data isolation, consent management, audit trails

Cloud Platform Integration

Amazon Web Services (AWS)

Integration points:

Deployment:

• Docker Swarm or ECS (Elastic Container Service)
• RDS for PostgreSQL, ElastiCache for Redis
• CloudWatch for monitoring, CloudTrail for audit

Microsoft Azure

Integration points:

Deployment:

• Azure Kubernetes Service (AKS) or Container Instances
• Azure Database for PostgreSQL, Azure Cache for Redis
• Azure Monitor, Application Insights

Google Cloud Platform (GCP)

Integration points:

Deployment:

• Google Kubernetes Engine (GKE) or Cloud Run
• Cloud SQL for PostgreSQL, Memorystore for Redis
• Cloud Monitoring, Cloud Logging

Identity Federation

Supported Federation Protocols

Multi-Issuer JWT Validation

Configuration:

jwt:
  issuers:
    - issuer: https://auth.ankatech.co
      audience: https://api.ankatech.co
    - issuer: https://customer.com/auth
      audience: https://api.ankatech.co
    - issuer: https://login.microsoftonline.com/{tenant-id}/v2.0
      audience: https://api.ankatech.co

Supported identity providers:

• Auth0: Native OAuth 2.0/OIDC integration
• Okta: Native OAuth 2.0/OIDC integration
• Ping Identity: Native OAuth 2.0/OIDC integration
• Azure AD: Native OAuth 2.0/OIDC integration
• AWS Cognito: Native OAuth 2.0/OIDC integration
• Keycloak: Native OAuth 2.0/OIDC integration

Token Structure

Standard JWT claims validated:

• iss (issuer)
• aud (audience)
• exp (expiration time)
• nbf (not before)
• iat (issued at)
• jti (JWT ID for revocation)

Custom claims required:

• tenantId (tenant isolation)
• scopes (permission grants)

Import & Export Formats

Import Capabilities

Keystore formats:

Endpoint:

Import is a control-plane operation on the Admin API:

POST /api/v3/admin/tenants/{tenantId}/keys/import-keystore

Request (multipart/form-data):

- keystore: [binary keystore file]
- metadata: [JSON import metadata, including the kid]
- password: [keystore password, omitted if unprotected]

Response:
{
  "kid": "imported-key",
  "algorithm": "RSA-2048",
  "imported": true
}

See: the step-by-step import procedure is delivered with a licensed deployment.

Export Capabilities

Export formats:

Restrictions:

• ❌ Private keys NEVER exported (security boundary)
• ✅ Public keys exported for key distribution

Endpoint:

GET /api/v3/admin/tenants/{tenantId}/keys/{kid}/export

Response (JSON): the key metadata plus "publicKey", the Base64-encoded public key
(or "components" for a composite key). Private material is never returned.

Example of the same public key once wrapped in an X.509 certificate by your own tooling:
-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKL0UG2vL9HHMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
...
-----END CERTIFICATE-----

See: Utility Operations

External Key Usage

ANKASecure supports cryptographic operations with keys generated outside the platform:

Scenarios:

1. Import PKCS#12 keystore → Use for ANKASecure operations
2. Generate key with OpenSSL → Import certificate → Encrypt for external party
3. Receive encrypted data → Import recipient key → Decrypt

See: import is a control-plane operation on the Admin API, POST /api/v3/admin/tenants/{tenantId}/keys/import-keystore; the step-by-step import procedure is delivered with a licensed deployment.

API Interoperability

RESTful API Design

Standards compliance:

API documentation:

• Swagger UI: /swagger-ui/index.html
• OpenAPI spec: /v3/api-docs
• ReDoc UI: /redoc

Error Response Format (RFC 7807)

{
  "type": "https://docs.ankatech.co/errors/payload-too-large",
  "title": "Payload Too Large",
  "status": 413,
  "detail": "Data size exceeds the maximum allowed limit of 4000000 bytes.",
  "instance": "/api/v3/crypto/encrypt",
  "correlationId": "550e8400-e29b-41d4-a716-446655440000",
  "timestamp": 1736937000,
  "extensions": null
}

SDK & Client Library Support

Official SDK:

• Java SDK: Native library with JOSE, streaming, PQC support

Client generation:

• OpenAPI Generator: Generate clients for Python, Go, JavaScript, .NET, Ruby
• Swagger Codegen: Alternative client generation

Standard library compatibility:

• Nimbus JOSE+JWT (Java): Compatible JWS/JWE format
• jose4j (Java): Compatible JWS/JWE format
• python-jose (Python): Compatible JWT validation
• jsonwebtoken (Node.js): Compatible JWT validation

Compliance Matrix

The tables below map requirements to the platform capabilities that support them.

Industry-Specific Requirements

Regional Standards

See: Regulatory Compliance Matrix

External Standards Bodies

Active Participation

ANKASecure aligns with guidance from:

Standards References

NIST:

• CSWP 39-upd1: Considerations for Achieving Crypto Agility: Strategies and Practices (hybrid cryptographic algorithms in §3.2.4)
• SP 800-208: Recommendation for Stateful Hash-Based Signature Schemes
• FIPS 203/204/205: Post-Quantum Cryptographic Standards

ETSI:

• ETSI TS 119 312: Electronic Signatures and Infrastructures (ESI); Cryptographic Suites
• ETSI TR 103 570: Quantum-Safe Cryptography (QSC)

GSA:

• Post Quantum Cryptography Buyer's Guide (June 2025): considerations for buyers of PQC products, services and solutions

See:

• NIST CSWP 39 Alignment^*
• ETSI TS 103 744 Alignment

Quick Reference

Standards Checklist

Cryptographic formats:

• ✅ JOSE (JWS, JWE, JWT) - RFC 7515-7519
• ✅ PKCS#7/CMS conversion - RFC 5652
• ✅ X.509 certificates - RFC 5280
• ✅ PKCS#12 keystores - RFC 7292

Post-quantum cryptography:

• ✅ NIST FIPS 203 (ML-KEM)
• ✅ NIST FIPS 204 (ML-DSA)
• ✅ NIST FIPS 205 (SLH-DSA)
• ✅ IETF composite ML-KEM and composite ML-DSA (Internet-Drafts)

Authentication:

• ✅ OAuth 2.0 - RFC 6749
• ✅ OpenID Connect - OIDC Core 1.0
• ✅ JWT validation - RFC 7519

API design:

• ✅ OpenAPI 3.0
• ✅ REST principles
• ✅ RFC 7807 (Problem Details)

Security event interop (SIEM/XDR):

• ✅ CEF v0 (ArcSight/QRadar/Splunk)
• ✅ OCSF (cloud SIEM / XDR)
• ✅ Syslog RFC 5424 (UDP/TCP/TLS-TCP)

The native Security Event Forwarder delivers signed audit events to a customer SIEM/XDR in these formats, preserving the ANKASecure HMAC signature end-to-end for independent verification.

Regulatory:

• ✅ OWASP Top 10
• ✅ GDPR, HIPAA and PCI DSS encryption requirements (requirement mapping, not an attestation)
• ✅ NIST SP 800-series
• ✅ CNSA 2.0 readiness

Related Documentation

Foundational Concepts

• JOSE Technical Reference
• Detached Signatures & Streaming Explained
• Hybrid vs Composite Keys

Compliance & Standards

• IETF Composite ML-KEM and Composite Signatures — Alignment
• OWASP API Security Alignment
• Regulatory Compliance Matrix
• FIPS 140-3, Random Bit Generation and Approved Algorithms

Migration & Interoperability

• PKCS#7 to JOSE Conversion
• Migration API Reference - the migration endpoints and their contracts

Strategic Context

• From PKCS#7 to JWS/JWE: The Evolution of API Security^*

Document Status: ✅ ACTIVE

Last Updated: January 2025

Document Location: 02-concepts/interoperability-standards.md

Target Audience: Solution Architects, Compliance Officers, Integration Engineers

Feedback: For corrections or additions, contact the documentation team.