Skip to main content

Minutes interim-2021-cose-01: Wed 16:00

Meeting Minutes CBOR Object Signing and Encryption (cose) WG
Date and time 2021-01-20 16:00
Title Minutes interim-2021-cose-01: Wed 16:00
State Active
Other versions markdown
Last updated 2021-02-02


COSE Virtual Interim

Connection details


  • Ivaylo Petrov
  • Matthew Miller
  • Francesca Palombini
  • Peter Yee
  • Göran Selander
  • John Preuß Mattsson
  • Jonathan Hammell
  • Laurence Lundblade
  • Carsten Bormann, TZI
  • Joel Höglund
  • Marco Tiloca, RISE
  • Ben Kaduk
  • Michael Richardson
  • Stefan Hristozov

Action Items

  • Ben to review issues for cose-X509, and update ballot position.
  • Chairs to review early codepoint allocation for countersign
  • Laurence Lundblade will post an issue about cbor sequence
  • [speculative; compressed CSR may affect rechartering]
  • Göran Selander to draft text to update charter proposal.
    • Revocation, CSR?


1. Administrivia (Chairs) - 5 min

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

  • hash-algs
  • rfc8152bis-algs
  • rfc8152bis-struct
  • Counter-sign - last call result
  • x509
  • rechartering

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.

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 (

( Selected Issues )

  • CBOR encoding of CSR (#77)
    Stefan Hristozov: for ad-hoc signing requests, we think having a representation for CSR is needed
    CB: I think it's good to evolve this in parallel. The best way is to keep them in the same document, but if it's too difficult we can extract to a separate document later.
    (MR in chat -- keep in the same document)
    IP: Would this impact the charter?
    GS: Let's come back to that

  • CSR for static DH keys (#80)
    (JH in chat -- Using MAC for CSR may also help for PQ algs, where an encryption key cannot be used for signing)
    SH: This means the CA also authenticates the static DH key. Is it possible to have something like a cert with the static DH but that is signed, and how would proof-of-possession be shown.
    GS: I'm not exactly sure how this all plays out together.

  • CBOR encoding of CRL (#68)
    CB: Definitely should encode OCSP, but not sure about use case for CRL
    BK: We should definitely have some way to convey revocation, but not sure which ones make the most sense.

  • File format of CBOR certificate (#81)
    MR: Thinking about how to do the "magic number" idea in CBOR ... maybe the format is a sequence where the first entry is the magic number and the second is the CBOR compressed cert. Keeping it together would be really useful when it hits the disk.
    GS: Maybe we should ping the CBOR WG about thoughts.

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