[Rats] Re: CoRIM signing

[Yogesh Deshpande <[e-mail]>]

Hi Jeremy,

In todays CoRIM call, we discussed your point and agreed to support the below requirement.

The following github issue is tracking this:
https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/583

Will provide the PR shortly.

Regards,
Yogesh

From: Jeremy O'Donoghue <[e-mail]>
Sent: Friday, May 22, 2026 3:32 PM
To: Yogesh Deshpande <[e-mail]>; rats <[e-mail]>
Subject: Re: CoRIM signing

Hi Yogesh,

I agree that a single Authority is responsible for ownership of a CoRIM, however consider the following problem: A manufacturer wishes to produce a CoRIM relating to some product or deliverable. Some customers can require single ML-DSA signature, some require hybrid ML-DSA with ECDSA, some have not yet enabled PQC crypto infrastructure and some Chinese customers require SM2-DSA. In some cases these cryptographic requirements might be regulatory.

In this case, the manufacturer either produces four internally identical but differently signed CoRIMs to comply with the present specification or it produces one multiply signed CoRIM where the same signing authority has simply used different cryptographic mechanisms to endorse. I do not think the countersignature case covers this ideally as a countersignature serves as a notarization by a different counterparty whereas in the use-case I describe - which I believe occurs inevitably in a diverse cryptographic environment - we have different mechanisms all representing endorsements by the same owner.

Glad to hear that the second point is covered and I look forward to the new draft.

Best regards
Jeremy
________________________________
From: Yogesh Deshpande <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, May 20, 2026 10:03
To: Jeremy O'Donoghue <[e-mail]<mailto:[e-mail]>>; rats <[e-mail]<mailto:[e-mail]>>
Subject: RE: CoRIM signing


WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Jeremy,



Thanks for the review and getting back to the CoRIM Authors.



  1.  For Signed CoRIMs we anticipate a single source of Authority taking ownership of CoRIM (hence signing via COSE_Sign1) and then there can be multiple Counter Signatures Endorsing the same CoRIM. Counter Signatures are fully supported as per COSE Spec: https://datatracker.ietf.org/doc/rfc9338/



  1.  For your second point we have already noticed the anomaly and hence please see : https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/575



The spec Version 11, will have a clear statement that would indicate use of separate triples, as you suggested:

using multiple reference-value-triples.





Regards,

Yogesh



From: Jeremy O'Donoghue <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, May 19, 2026 9:53 PM
To: rats <[e-mail]<mailto:[e-mail]>>
Subject: [Rats] CoRIM signing



Hi CoRIM editors,



A couple of points on draft-ietf-rats-corim-10.



I believe there are valid use-cases for a Signed CoRIM to have multiple signeds (i.e. allow COSE_Sign in addition to COSE_Sign1.



An example of such a use-case is a dual-signed artifact (e.g. signed by a silicon vendor and an OEM, or both classically and PQC signed). The alternative would be to produce separate sets of CoRIM with the same payload.



I believe this would be a straightforward change.



In addition, I have a question on the text:

The ref-claims in a reference-triple-record can contain one or more entries. This multiplicity can have different meanings:

  1.  Each ref-claims entry can represent a different possible state of the Environment.

  1.  Each ref-claims entry can represent a possible state of a different measured element (identified by its mkey) within the Environment.

Note that the same semantics can be expressed using multiple Reference Value Triples.

Allowing different meanings for the same record seems like a recipe for interoperability problems in future. Is there a good reason for this rather than either defining a new triple (dependent-value-triple-record) or simply using multiple reference-value-triples.



Best regards

Jeremy
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.