COSE IETF 114 ==================== # Connection details * Date: July 26, 2022 * Meeting recording: https://www.youtube.com/watch?v=d0zOUQ26qt0 * Slides link: https://datatracker.ietf.org/meeting/114/session/cose # Action Items * Hannes to review C509 draft. * Chairs to push x509 -09 * PW - double check reference in -countersign document # Minutes ## Opening remarks by the chairs – Ivaylo Petrov [1:30-1:35] https://datatracker.ietf.org/meeting/114/materials/slides-114-cose-opening-remarks-by-the-chairs-01 Marco Tiloca - Note taker John Mattsson backed by the chairs - Monitoring Jabber ## Document Status – Ivaylo Petrov [1:35-1:40] https://datatracker.ietf.org/doc/slides-114-cose-cose-114-draft-status/ PW: We really need to get this cluster of documents out. Please people act in the next 2 weeks so that we can proceed with publication. BK: 2 week time looks good. I have a potential open issue I raised and requested for input. PW: Will follow-up. MT: Section 3 of the -countersign document refers to a CoRE document, but a different one than in the previous version. I think the old reference is more appropriate, that's when the countersigning happens. I will send a mail to the Last Call thread. PW: We discussed it this morning. I'll also double check it. ## draft-ietf-cose-hpke – Hannes Tschofenig [1:40-1:50] HT (p2): which key format to use? Raw data (Ilari's preference), or coordinates as in COSE? MJ (chair-hat off): Any reason to diverge from what defined in COSE? HT: Ilari has reasons to diverge. ??: In favor of P256 public key (COSE). ??: ? DB: No strong opinion, they look similar. MJ: Nobody speaks in favor of Ilari's proposal. PW: No need to, the COSE format looks preferred anyway. RH (p3): Proposed to register encryption algorithm without integrity protection. Useful in work ongoing in SUIT. ??: ? JH: Would the guidance you mention be put in the registry itself? RH: It would be in IANA consideration. JPM: I support registering encryption without integrity; it came up before, e.g. in Group OSCORE BM: Not practical to require integrity verification before decryption in cases like encrypted firmware. RH: Which can lead to burning out flash. BM: Yes and not only. BK: I support such registrations; need to include good considerations. JB: We didn't want to have this. Is there the possibility to encrypt and then sign? I wouldn't rush to make a general exception for COSE. MJ: There are precedents of algorithms registered as deprecated. (Discussion in the chat about consequences of lack of integrity protection outside of payload.) ## draft-ieft-cbor-encoded-cert - John Mattsson [1:50-2:00] JPM: Just submitted a new version to not make it expire; not much time to work on new content. Work is going on with a MSc student. People has expressed interest also for implementations. A C implementation should be available soon. JPM: Got comments about the subtree and on the document structure, to be processed. IP: Anyone willing to review? (Hannes volunteers) ## draft-looker-cose-bls-key-representations – Tobias Looker [2:00-2:10] TL: overviewing the draft content. We'll produce examples. ## draft-looker-cose-cwt-claims-in-headers – Tobias Looker [2:10-2:15] TL: overviewing the draft content. MP: Thanks, extremely useful. CB: Good idea to transport CWT claims with any COSE structure. Not sure what it specifically means. CWT claims are defined to make sense in a certain context, here they are used in a different context, which can result in unclear things. For instance, if I use the not-before claim with firmware update, what does it mean? \[Carsten explains that multiple COSE header parameters could be defined that can carry CWT claims and each give different semantics to the CWT claims included in them.] LL: If it's CWT, it's for authentication, with its semantics. It seems related to the content-type, in the COSE header or in the surrounding context. CB: Should you put CDDL? I think so. ## Post quantum representations (Orie Steele) [2:20-2:25] MP: proposing envelopes and encoding for PQC algorithm, no hardcore crypto. BM: Do you mean key encapsulation/representation or key establishment? ??: Avoiding any key encapsulation at the moment, just signatures. BK: But you're also looking at key representation. MP: Yes. JM: We should ensure that this is not published before NIST has published its standards. OS: Fully agree. MJ: Possible to get a draft to a final status as RFC Editor's Queue, and to hold it there waiting for normative references (e.g., algorithm definition). But certainly better to work in parallel. PW: Please join the PQC list that we've created. JPM: What about hybrid systems? This should be discussed and possibly supported. MP: Already discussing about that. OS: Aiming at bringing it in the Working Group. MJ: Anyone against a call for adoption? (none heard) MJ: Chairs will issue a call for adoption. ## draft-selander-cose-kid-int – Göran Selander [2:15-2:20] ## Open Microphone ## Abbreviations in the notes PW -> Paul Wouters MJ -> Mike Jones HT -> Hannes Tschofenig RH -> Russ Housley JPM -> John Mattsson BK -> Benjamin Kaduk LL -> Laurence Lundblade CB -> Carsten Bormann IP -> Ivaylo Petrov MP -> Michael Prorock TL -> Tobias Looker MT -> Marco Tiloca BM -> Brendan Moran OS -> Orie Steele