RFC 9052 Quiz (EN)

Q1: Which COSE header statement is correct?

Multiple Choice

An A2A profile uses COSE_Sign1 and must know which header values are covered by the signature.

A. Both header buckets are signed because they appear next to each other in the COSE_Sign1 array B. Neither bucket can be signed; only the payload is part of the COSE signature structure C. The protected bucket is in Sig_structure; an unprotected value needs a separate authenticated binding for security use D. The unprotected bucket takes precedence whenever the same label is also present in protected headers

**Explanation:** A: Section 3 defines separate protected and unprotected buckets; adjacency does not authenticate the unprotected map. B: Section 4.4 includes protected attributes as well as the payload and external data in Sig_structure. C: Correct. Sections 3 and 4.4 define the protection boundary; a profile must not infer authenticated semantics from an unprotected value alone. D: Section 3 says the protected value is used if a label appears in both buckets, though applications should detect that duplication.

Q2: What may the verifier infer from an unprotected kid?

Multiple Choice

A COSE_Sign1 object contains kid=h'17'. Three configured keys share that kid, but only one is authorized for this A2A issuer.

A. Use kid as a lookup hint, try the applicable candidates, and separately enforce the selected key's issuer authorization B. Treat kid as globally unique and select the first matching key without checking its identity association C. Reject because kid is security-critical and therefore can never appear in the unprotected header bucket D. Accept the claimed issuer once any configured key has a matching kid, before verifying the COSE signature

**Explanation:** A: Section 3.1 says kid is a non-unique key-selection hint. Section 4.4 separately requires the application to pair the verified key with an authorized signing identity. B: Section 3.1 explicitly says applications must not assume kid values are unique. C: Section 3.1 permits kid in the unprotected bucket because it is not itself security critical. D: A matching identifier is not signature verification or an issuer-to-key trust decision.

Q3: Is the profile's algorithm placement acceptable?

Multiple Choice

A COSE_Sign1 profile places alg only in the unprotected bucket. The verifier selects its verification algorithm from that value. The requirement is to prevent an intermediary from changing the algorithm selection while preserving the rest of the message.

A. Accept the design because every registered COSE algorithm identifier has integrity protection from the IANA registry B. Accept it when kid is protected, since authentication of a key identifier also authenticates any unprotected alg value C. Keep alg unprotected and try all locally allowed algorithms, using the first verification that succeeds D. Put alg in protected headers or bind it through authenticated external data, then apply the profile's allowed-algorithm policy

**Explanation:** A: A registry assigns semantics and code points; it does not protect a parameter instance in a message. B: Protection of one parameter does not extend to a separate unprotected parameter. C: Algorithm trial can create a different or ambiguous processing rule and does not meet the stated authenticated-selection criterion. D: Section 3.1 requires alg to be authenticated where the ability exists and identifies protected headers or external data as the mechanisms. Algorithm acceptance remains profile policy.

Q4: How should the verifier process this crit value?

Multiple Choice

A COSE_Sign1 object places crit=[1001] in protected headers, but parameter 1001 appears only in the unprotected bucket. The A2A profile says 1001 changes authorization semantics when understood.

A. Read 1001 from the unprotected bucket because crit is protected and therefore authenticates any value carrying the named label B. Treat this as a fatal processing error because a label named by crit is not present in the protected-header bucket C. Ignore crit and use 1001 only if the local application already understands its unprotected representation D. Move 1001 into protected headers after receipt and verify the original signature against the modified structure

**Explanation:** A: crit lists protected parameters that must be understood; it does not authenticate an unprotected value with the same label. B: Section 3.1 explicitly makes this condition a fatal error. C: Ignoring a valid protected crit list defeats the sender's critical-processing requirement. D: Changing protected headers changes Sig_structure and cannot retroactively repair the received signature.

Q5: Why must this detached-payload verification fail?

Multiple Choice

The signer creates COSE_Sign1 with a detached payload and external_aad equal to the ASCII bytes of POST /tasks. The verifier uses the same payload bytes but supplies an empty external_aad. The profile requires the HTTP method and path to be bound to the signature.

A. Sig_structure differs, so verification must use the exact profile-defined external_aad bytes before the request can meet the context-binding rule B. Verification can succeed because external_aad is never included in the COSE signing input and serves only as local metadata C. Verification can omit external_aad when the payload is detached, since transporting payload separately also detaches its application context D. The verifier should reconstruct external_aad from any equivalent URL spelling because COSE signs the parsed HTTP semantics rather than bytes

**Explanation:** A: Sections 4.3 and 4.4 require both sides to construct the same external data byte string, and Sig_structure includes it before the full payload. B: Section 4.4 explicitly includes external_aad in Sig_structure. C: Detached transport changes where the payload is carried, not the payload or external context included in the signing input. D: COSE consumes application-supplied bytes. The A2A profile must define normalization if multiple HTTP spellings are to be equivalent.

Q6: Which design gives the backend the evidence required by its policy?

Multiple Choice

An A2A gateway verifies a COSE_Sign1 request and confirms that its key is authorized for issuer I. It forwards decoded sub and role in ordinary HTTP headers. The backend owns the resource and requires authenticated issuer, role, payload digest, and operation context. It does not receive the COSE object or protected gateway evidence.

A. Use the ordinary headers because Section 4.4 verification causes all decoded fields to remain authenticated after reserialization B. Add the original unprotected kid header, allowing the backend to recover issuer, role, payload digest, and operation context C. Let the backend verify the original COSE inputs, or make the gateway a trusted issuer of a protected assertion that explicitly covers the required facts D. Treat gateway TLS as proof of the original issuer and role, even if the downstream request carries no integrity-protected mapping to those values

**Explanation:** A: Sections 3 and 4.4 define which original bytes are authenticated; decoded ordinary headers do not inherit that protection. B: Section 3.1 says kid is a non-unique lookup hint, not a container for the backend's required evidence. C: Section 4.4 supplies COSE verification and requires application checks for key, identity, and authorization. The downstream assertion is a separate A2A trust-boundary design and must protect its stated semantics. D: Gateway TLS authenticates the immediate connection, not an unstated mapping from original COSE evidence to downstream fields.

COSE: Structures and Process

References (URLs)

Q1: Which COSE header statement is correct?

Q2: What may the verifier infer from an unprotected kid?

Q3: Is the profile's algorithm placement acceptable?

Q4: How should the verifier process this crit value?

Q5: Why must this detached-payload verification fail?

Q6: Which design gives the backend the evidence required by its policy?