Package co.ankatech.ankasecure.sdk.examples

Class ExampleScenario20

java.lang.Object
co.ankatech.ankasecure.sdk.examples.ExampleScenario20
public final class ExampleScenario20 extends Object
Scenario 20 — PKCS#7 → JOSE Conversion / Migration (data-plane).

Converts a legacy PKCS#7/CMS EnvelopedData artifact to a modern JOSE JWE. Unlike the keyless analysis in ExampleScenario19, conversion of EnvelopedData requires the platform to actually decrypt the CMS envelope and re-wrap it — so it needs the recipient's private key, referenced by its platform key id.

Where the recipient key comes from (control-plane prerequisite)

  • The recipient key is matched by issuer DN + serial number, NOT by algorithm — so it cannot be discovered from the algorithm catalogue.
  • Importing that key from a legacy keystore is a control-plane operation handled outside the data-plane SDK (the admin migration surface, an admin-scoped actor).
  • This data-plane example therefore reads the resulting key id from the explicit pkcs7.decryptionKid property and skips cleanly (before any server call) if it is absent.

Capability Grants the calling actor needs (control-plane prerequisite)

The migration.convertPkcs7 scope admits the route; the keys are admitted by the calling Cryptographic Actor's Capability Grants, which the platform decides per leg with the re-operation capabilities, never with ENCRYPT, DECRYPT or SIGN:

  • REENCRYPT over [decryptionKid, recipient] for every recipient of the EnvelopedData, the decrypting key's own pair included. A REENCRYPT/RESIGN grant is requested with exactly two assetKids and admits any request whose kids it contains. This single-recipient fixture needs the in-place grant, requested with the kid twice (assetKids: [decryptionKid, decryptionKid]) and stored as [decryptionKid]; N recipients need a pair grant [decryptionKid, recipient] to each other recipient. There is no wildcard re-operation grant.
  • RESIGN over each signer's in-place pair (assetKids: [signer, signer]), for a SignedData or SignedAndEnvelopedData input.

The tenant, the Application and the Actor must be active. A grant is created on the control plane (POST /api/v3/admin/tenants/{tenantId}/capability-grants), outside this SDK; an actor without it is refused with HTTP 403 before any key is resolved.

Steps:

  1. Resolve the recipient key id from the pkcs7.decryptionKid property (skips cleanly when blank)
  2. Compact convert: convertPkcs7ToJose (AUTO format → EnvelopedData becomes JWE)
  3. Streaming convert: convertPkcs7ToJoseStream to a JWE output file
  4. End-to-end: performMigrationWorkflow (analyze + convert in one call)

Target-format contract

TargetFormatEnum.AUTO detects the structure: EnvelopedData → JWE, SignedData → JWS, both → nested. Forcing JWS on EnvelopedData is a 400 contract error (there is no signature to convert); this example uses AUTO / JWE.

API Endpoints:

  • POST /api/v3/migration/convert-pkcs7-to-jose (compact conversion)
  • POST /api/v3/migration/stream/convert-pkcs7-to-jose (streaming conversion)

Prerequisite: a cli.properties for a data-plane actor holding the REENCRYPT grant above, plus a pkcs7.decryptionKid entry naming a recipient key already provisioned on the platform. Until that key and grant exist the conversion calls are refused by the server; the analysis counterpart ExampleScenario19 needs no key and runs unconditionally.

See Also:

  • Method Details

    • main

      public static void main(String[] args)
      Runs the PKCS#7 → JOSE conversion / migration scenario.
      Parameters:
      args - command-line arguments (ignored)