Intercambiar datos con herramientas JOSE estándar
Trabaja con una parte externa a la plataforma usando la clave pública de esa parte: verifica un JWS que firmó con herramientas JOSE estándar, o cifra un archivo para ella. La clave pública que proporcionas se usa en esa única solicitud y nunca se guarda como clave de tu tenant.
Quién puede hacerlo
Una aplicación autenticada como actor criptográfico de tu tenant, cuyo token lleva:
interoperability.verifySignaturepara verificar una firma con una clave pública proporcionada;interoperability.encryptpara cifrar con una clave pública proporcionada.
No interviene ninguna concesión de capacidad, porque no se usa ninguna clave de tu tenant. Ningún rol de la consola realiza estas operaciones.
Antes de empezar
- Tienes la clave pública de la otra parte, codificada en Base64, con su tipo de clave y su algoritmo.
- Para verificar, tienes los datos firmados y el JWS separado en forma JSON aplanada (
{"protected", "signature"}), con una sola firma. - La aplicación puede obtener un token. Consulta Obtener un token de acceso para una aplicación.
- Son operaciones de streaming, y no se ejecutan con el transporte de sesión PQC.
Pasos
- Verifica una firma hecha por la otra parte:
- SDK de Java:
sdk.verifySignatureUtilityStream(kty, alg, publicKeyBase64, signatureBase64, dataFile)devuelve unVerifySignatureResult; leeisValid(). - CLI criptográfica:
AnkaSecureCLI verify-signature-publickey-stream --kty <kty> --alg <alg> --public-key <file> --input-signature-file <file> --input-file <file>, donde--public-keynombra un archivo JSON con un campopublicKeyen Base64. - API:
POST /api/v3/interoperability/verifycon un cuerpomultipart/form-data:metadata(el JWS separado y la clave pública) antes defile(los datos firmados).
- SDK de Java:
- El propio
algprotegido del JWS selecciona el esquema y debe corresponder a la clave:RS256,RS384,RS512,PS256,PS384oPS512para una clave RSA; el único algoritmo ECDSA de la curva de una clave EC, comoES256para P-256;EdDSA,Ed25519oEd448para una clave Edwards; el nombre del conjunto de parámetros, comoML-DSA-65, para una clave de firma post-cuántica. Se ignora cualquierkiddel encabezado. - Cifra un archivo para la otra parte:
- SDK de Java:
sdk.encryptFileUtilityStream(kty, alg, publicKeyBase64, input, output)devuelve unEncryptResult. - CLI criptográfica:
AnkaSecureCLI encrypt-file-publickey-stream --kty <kty> --alg <alg> --public-key <file> --input-file <file> --output-file <file>. - API:
POST /api/v3/interoperability/encryptconmetadata(kty,alg,publicKey) antes defile(el texto en claro); el texto cifrado se devuelve en streaming.
- SDK de Java:
Qué ves cuando funcionó
Una verificación responde 200 con valid y una entrada de signatureResults que lleva el algoritmo que declaraste y ningún identificador de clave ni versión de material, porque la clave no es una clave de la plataforma. valid es false cuando la firma no se verifica con la clave proporcionada.
Un cifrado devuelve el texto cifrado en streaming; el SDK y la CLI lo escriben en el archivo de salida.
Si falla
| Qué ves | Causa | Qué hacer |
|---|---|---|
200 con valid: false | La firma no se verifica con la clave proporcionada | No confíes en los datos |
422 con JWS_SINGLE_SIGNATURE_REQUIRED | El JWS lleva varias firmas; una clave proporcionada verifica una sola firma | Verifica cada firma con su propia clave, o usa la verificación propia de la plataforma para las claves de la plataforma |
422 .../errors/unprocessable-entity | El alg protegido es none, falta, es un algoritmo HMAC o compuesto, o no corresponde a la clave; o la clave proporcionada no es del conjunto de parámetros o de la curva que nombra su alg | Proporciona la clave y el algoritmo que correspondan |
400 .../errors/invalid-input | El material de clave, el JWS o el cuerpo multiparte no es válido, o alg no nombra ningún conjunto de parámetros | Corrige la solicitud |
400 .../errors/pqc-transport-not-available-for-streaming | La solicitud se envió con el transporte de sesión PQC | Vuelve a enviarla sin los encabezados X-PQC-Transport y X-PQC-Session |
403 | La aplicación o el actor que llama está suspendido o deshabilitado, o al token le falta el scope | Pide a un administrador del tenant que revise el actor |
408 .../errors/stream-read-budget-exceeded | La carga no se recibió dentro del tiempo máximo del despliegue | Vuelve a intentarlo con una conexión más rápida, o con un archivo más pequeño |
429 con Retry-After | El límite de concurrencia de streaming está lleno | Vuelve a intentarlo después del tiempo indicado |
Sin la consola
Estas operaciones no tienen pantalla en la consola.
| Superficie | Cómo |
|---|---|
| SDK de Java | verifySignatureUtilityStream, encryptFileUtilityStream en AuthenticatedSdk |
| CLI criptográfica | AnkaSecureCLI verify-signature-publickey-stream, encrypt-file-publickey-stream |
| API | POST /api/v3/interoperability/verify (verifyInteroperable), POST /api/v3/interoperability/encrypt (encryptInteroperable) |
Relacionado
- Firmar y verificar datos: firmas hechas con las claves de tu tenant.
Esta página está en inglés: