COSE Virtual Interim

Connection details

Attendees

Action Items

Minutes

1. Administrivia (Chairs) - 5 min

2. Update on drafts status and charter (Chairs) - 5 min

[x509] LL: there are still open issues on cose-x509 in github, and I don't know what the telechat tomorrow is IP: looks like we have some about x5u; do you think those might require more than editorial changes? BK: thanks for asking; I'll check those before I reballot for the IESG telechat tomorrow. LL: It basically seems the same as JWS and if JWS is wrong, we should file errata [or update] it. MCR: JWS had to deal with an existing ecosystem; we can do clean slate for compressed certs LL: this is cose-x509, not just comperssed certificates MCR: ah, right, maybe we should update JWS LL: we do have x5bag that JWS doesn't, so there are some differences. But you got the point, thanks. Carsten: we had a chance to learn from JWS; Jim tried to learn from that; and that's why cose-x509 is different from JWS in some details. It might be worth documenting what's different and why. BK: same doc or separate document? CB: such a doc would be best if it included cose-x509 experience as well, so separate document, though that leaves an interim period where understanding this doc is harder.

[countersign] Jonathan Hammell: I raised question onlist about status of early codepoint allocation. IP: chairs were supposed to look at it; still an open action item. Michael, do you think it's just a matter of checking the examples, or could any other problems/changes arise? MCR: that's correct

3. CBOR Certificates - 40 min

JM: two presentations: changes made, and (from Göran) open issues MR: You are talking about compression across certificates, but we haven't done anything about that. CBOR-pack might be the right way to go. CB: It is really hard to define a profile without a good set of use-cases. This is one where we can really experiment with, so we could have a base document to define mechanism and another document that applies the experiment. MR: If dealing with compression of chains of certs, what happens if we just take some simple CBOR representation and apply CBOR-pack. A single cert will gain us nothing. CB: Depends on whether issuer and subject are in the same organization. MR: Also the possibility that CBOR-pack could apply to the whole structure. CB: We could define a static dictionary for 'compressed cert', and that would be part of the profile. JM: The integer refers to the field in the next certificate in the chain. But you would have to uncompress to verify the signature. LL: Is there anything about certificate size vs. code size? JM: My code size did not increase much (in my implementation), but I did have to reorganize to support it. LL: Ask because these are a lot of little tweaks, and each adds a little bit of code. JM: I think it might be worth exploring, and it's possible that if it's CBOR-pack your codesize is not really increasing. IP: Any thoughts on how to evaluate the different concepts while trying to optimize? JM: I think it depends on what we do; I could add comparisons from this to brotli, and someone could add versus CBOR-pack. The indication is we should look more at the chain. LL: Wrote an email about using CBOR sequence and its implications, but haven't seen any responses. JM: I missed that email, will take a look. GS: Please post an issue (https://github.com/EricssonResearch/CBOR-certificates)

( Selected Issues )

Impacts on charter GS: maybe we should add something to the charter for recovation? SH: This is very interesting to me. IP: Definite interest, and no opposition, so Göran can you draft some text to discuss.

4. AOB - 10 min