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