Minutes IETF114: cose
minutes-114-cose-00
Meeting Minutes | CBOR Object Signing and Encryption (cose) WG | |
---|---|---|
Date and time | 2022-07-26 17:30 | |
Title | Minutes IETF114: cose | |
State | Active | |
Other versions | markdown | |
Last updated | 2022-08-04 |
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