Hello,
While proposing an extension to go-cose (https://github.com/veraison/go-cose)
for supporting countersignatures using RFC 9338, I felt a certain difficulty to
follow the documentation.
They were:
1. How to countersign COSE_Signature and COSE_Countersignature structures?
While forming the ToBeSigned value, chances are the “payload” may get different
interpretations. The section 3.3 says “the payload to be signed, encoded in a
bstr type”. In this case, may it be the target message payload (say from
COSE_Sign1 / COSE_Sign), or is it just the “signature” field of the
COSE_Signature/COSE_Countersignature structures? I understand it would be the
latter, so the countersignature attests just the parent's signature, which
means the entity had to go over the signature’s parent to verify it, working
recursively, towards the root’s structure.
2. How to countersign a COSE_Sign structure?
The question is how to interpret the “other_fields” from same section 3.3. It
says “all bstr fields after the second”. COSE_Sign has “signatures” as third
field, which is a list of COSE_Signatures, so technically the third field is
not a bstr but an array. In this case, the ToBeSigned value would be formed by
protected headers and the payload, but wouldn't include any signature, and
doing so means that a COSE_Sign countersignature would work just as another
COSE_Signature, except it may be placed as unprotected header. On the other
hand, the COSE_Sign “signatures” field can be serialized in a bstr, similarly
to what happens to “protected” headers. This would allow countersignatures to
attest the protected headers, the document and all signatures appended to it
until the signature was placed; however, prohibits further countersignatures at
individual signatures and other modifications at the unprotected headers. A
third possibility, which is not stated anywhere, but I wonder if it wouldn't be
handy, is the ability to include in the ToBeSigned value only the protected
headers and signature fields of each COSE_Signature structure appended to
COSE_Sign; this would allow extensibility of the structure, except of course
appending further signatures.
The example provided in
https://github.com/cose-wg/Examples/blob/master/countersign/signed-03.json
formed a ToBeSigned like
["CounterSignature", h'A10300', h'A10127', h'',
h'546869732069732074686520636F6E74656E742E’]
Which corresponds to:
- context: “CounterSignature”
- body_protected: / content-type / {3: 0} / text/plain; charset=utf-8 /
- sign_protected: / alg / {1: -8} / EdDSA /
- external_aad: none
- payload: "This is the content.”
Compare it with the COSE_Signature also from this same example:
["Signature", h'A10300', h'A10127', h'',
h'546869732069732074686520636F6E74656E742E’]
- context: “Signature”
- body_protected: / content-type / {3: 0} / text/plain; charset=utf-8 /
- sign_protected: / alg / {1: -8} / EdDSA /
- external_aad: none
- payload: "This is the content.”
The only diference is in the context, and it means a countersignature of a
COSE_Sign would be attesting the protected headers and the payload only,
excluding all signatures. I’m under the impression the
https://github.com/cose-wg/Examples repository is still following the
deprecated RFC 8152, but if the above is still the intent of RFC 9338, it means
the COSE_Sign countersignature is limited to witnessing the protected headers
and the payload, which, even though it is definitely an use case, may be a
restrictive case. As a corollary, COSE_Sign1 countersignature encompasses the
signature, why COSE_Sign would not?
Regards,
Guilherme._______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
