Skip to main content
Glama

CipherHUB Cryptography Toolkit

cose_sign1_sign

[cose_sign1] 构造并签名 COSE_Sign1 消息(RFC 9052 §4.2,算法 RFC 9053)。 【算法】ES256(-7, P-256+SHA-256) / ES384(-35, P-384+SHA-384) / ES512(-36, P-521+SHA-512) / EdDSA(-8, Ed25519)。ES 系签名为裸 r||s (坐标左补零到曲线宽度,ES512 坐标 66 字节、r||s 共 132 字节)。 【参数】

  • algorithm:ES256 / ES384 / ES512 / EdDSA

  • ecc_private_key_in_pem:EC 或 Ed25519 私钥 PEM(须与算法曲线匹配)

  • ecc_private_key_password:私钥口令(未加密则留空)

  • payload_in_hex:待签 payload(1B~256KB)

  • external_aad_in_hex:外部 AAD(可选,默认空串) 【输出】cose_sign1_in_hex(完整 COSE_Sign1)、protected_in_hex、 sig_structure_in_hex(Sig_structure 待签字节,RFC 9052 §4.4,可直送 openssl dgst 交叉)、signature_raw_in_hex(裸 r||s)、 signature_der_in_hex / r_in_hex / s_in_hex(EdDSA 无此形态)、structure_tree。 【注意】签名真正覆盖的是 Sig_structure = ["Signature1", protected, external_aad, payload] 的规范编码,不是 payload 本身。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
detachedNoTrue 时载荷带外(COSE payload 置 null / CMS eContent 缺省),验签必须提供外部内容;默认 False
algorithmNo密码算法名称(具体可选值因工具而异,见工具描述)ES384
payload_in_hexNoCOSE Sign1 待签 payload 的十六进制字符串(1B~256KB)
external_aad_in_hexNo外部 AAD 的十六进制字符串(可选;参与 Sig_structure 但不出现在消息里)
ecc_private_key_in_pemNoECC 私钥的 PEM 文本(含 BEGIN/END 头尾的 Base64 编码文本)
ecc_private_key_passwordNoECC 私钥的加密密码(原始字符串,非编码格式)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the disclosure burden and does well: it specifies the Sig_structure = ["Signature1", protected, external_aad, payload] coverage, the raw r||s padding convention, curve/key matching requirement, and password behavior. It omits any mention of permission preconditions or failure modes, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well organized with bracketed section headers (算法/参数/输出/注意) that front-load the algorithm choices and constraints. It is verbose, but each line carries technical content an agent needs, with little filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by enumerating every returned field (cose_sign1_in_hex, sig_structure, DER/raw signature forms). The detached-payload mode is only documented in the schema, leaving a small gap for a capable signing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (baseline 3), and the description adds meaning beyond the schema: algorithm-to-curve mapping with RFC algorithm numbers, ES512's 66-byte coordinate/r||s layout, the 1B–256KB payload constraint, and the key-must-match-curve rule. Still, the 'detached' parameter is left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('构造并签名 COSE_Sign1 消息') with concrete RFC standards (9052 §4.2, 9053). The scope is unambiguous and clearly distinct from siblings cose_sign1_verify and cose_sign1_parse without needing to open a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the signing semantics and the note on what the signature actually covers, which helps an agent understand the operation. However, there is no explicit when-to-use/when-not guidance nor routing to alternatives like cms_signed_sign or cose_sign1_verify for the verify path.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.