Why ./sign1-tests/sign-pass-01.json is categorized as a valid/pass scenario?

[jozkee]

From https://datatracker.ietf.org/doc/html/rfc8152#section-3.1 alg:

This parameter MUST be authenticated where the ability to do so exists... This authentication can be done either by placing the header in the protected header bucket or as part of the externally supplied data.

But the example https://github.com/cose-wg/Examples/blob/master/sign1-tests/sign-pass-01.json puts the alg in the unprotected bucket, the protected bucket is a0 (empty) and there is no externally supplied data.

Also, what does "Redo protected" mean in "title":"sign-pass-01: Redo protected"?

[thomas-fossati]

From https://datatracker.ietf.org/doc/html/rfc8152#section-3.1 alg:

This parameter MUST be authenticated where the ability to do so exists... This authentication can be done either by placing the header in the protected header bucket or as part of the externally supplied data.

But the example https://github.com/cose-wg/Examples/blob/master/sign1-tests/sign-pass-01.json puts the alg in the unprotected bucket, the protected bucket is a0 (empty) and there is no externally supplied data.

Agree this shouldn't be a test case that is marked as PASS, unless I am entirely misunderstanding the intent of the test case. In fact, there is this bit:

      "failures":{
         "ChangeProtected":"a0"
      },

which seems to suggest a failure is expected? I tried to interpret that against the CDDL schema but couldn't find an answer. BTW, it seems that we need to update the schema to match the example in question (e.g., the sign0 format is undefined and there is no sign1 in the CDDL, which I believe is what was intended).

[jfhamme-cccs]

Indeed, I've also confirmed that this example is mislabelled as it fails to validate. The protected headers are encoded as an empty serialized map, e.g. 0a, rather than an empty bstr. This aligns with the JSON "failures": { "ChangeProtected":"a0" } noted by @thomas-fossati .

RFC 8152 says the following about encodings of the protected headers:

      Recipients MUST accept both a zero-
      length binary value and a zero-length map encoded in the binary
      value...  (Badly behaved intermediates could decode and
      re-encode, but this will result in a failure to verify unless the
      re-encoded byte string is identical to the decoded byte string.)
      This avoids the problem of all parties needing to be able to do a
      common canonical encoding.

So it appears that the example was indeed designed to fail. Re-encoding the protected headers as an empty bstr seems to fix the signature.