Hi Russ,
On Wed, Apr 13, 2022 at 10:26 AM Russ Housley <[email protected]> wrote:
> Do you think anything needs to change in the document?
After re-reading the description in Section 3, I think the semantics
are clear for an implementer. The warning needs to be heeded that one
must consider the security properties when applying it. If one is
using a software library for COSE, I suppose that the resulting
security properties may not be obvious to the user, particularly in
the case of COSE_Sign. That said, any text we add in the RFC is
likely not to be read by a software library user, so it is the
responsibility of the library to provide a proper API to prevent
misuse.
The case of detached signatures might be a little unclear, as
Christian originally raised. Section 4.1 of RFC 8152 says that "If
the payload is transported separately ("detached content"), then a nil
CBOR object is placed in [the payload]..." A nil value is a different
CBOR type than an empty bstr (Section 1.3 of RFC 8152). However, Step
5 of Section 3.3 says that "the payload is placed [in the payload of
Countersign_structure] independent of how it is transported." I
believe this implies that the detached payload is indeed included here
for the purpose of countersigning, similar to externally supplied
data. But would an implementer then misinterpret Step 6 given that
the payload of the original structure was nil and not a bstr, and thus
not include the signature bstr in the other_fields?
The examples in the I-D certainly need to be updated. The first
example was taken from RFC 8152. It is odd given that it is a
countersignature on a COSE_Sign, which is discouraged in Section 3 for
the reasons discussed before, and it uses the same key to countersign
as was used in the original signature. That is, it has two ECDSA
signatures with the same key.
The early allocations that I requested for the countersignature header
parameters were never actioned, but the values chosen still seem to be
unassigned by IANA.
However, I will need to update the examples that I generated for
Appendix A since in a recent review of my code I believe I found a
bug. It would be nice to do an interoperability test with another
implementer, so please let me know if anyone wishes to test with me.
Best regards,
Jonathan
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
