# COSE WG @ IETF-108 Minutes

**When**: 2020-07-29 @ 13:00-13:50 UTC
**Where**: [Meetecho](https://meetings.conf.meetecho.com/ietf108/?group=cose&short=&item=1)

**Chairs**
* Ivaylo Petrov
* Matthew Miller

**[Notes/Minutes](https://codimd.ietf.org/notes-ietf-108-cose)**
* Francesca Palombini

**[Jabber](xmpp:cose@jabber.ietf.org?join)**
* Michael Richardson

## 0. Administrivia (Chairs) - 5 minutes (13:00 - 13:05)

* ~~Bluesheets~~
* Note taker(s): Francesca
* Jabber Scribe: Michael Richardson
* Agenda + Bartering
    - no agenda changes
* Meetecho Tips

## 1. Document Status (Chairs) - 5 minutes (13:05 - 13:10)
  * https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorithms/
  RFC editor 
  * https://datatracker.ietf.org/doc/draft-ietf-cose-x509/
  waiting AD review
  * https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/
  waiting AD approval
  * https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/
  waiting AD approval

### 1.1 Struct Discuss (Jim Schaad) - 10 minutes (13:10 - 13:20)
  * https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/
  * https://mailarchive.ietf.org/arch/msg/cose/yjKTObY8Gb387p6V4gwAFHts72g/


JS: Questions?

BK: Could you re-iterate the drawbacks for including all of the options?

GS: You don't want this to be individual per struct. Reason for that?

JS: Having a single alg makes things simpler. You don't have to figure out the object before computing or verifying the counter signature. Same process.

JS: Ben, the problem is not in current structures defined today, but rather in potential structure defined in the future.

BK: regardless of the option, we still have to worry about future structs.

CB: "change" mean it would change the interpretation of the existing struct, or put in something new that deprecates old?

JS: MAC* or sign_0 struct would be invalid. Change, not define something new.
CB: Maybe we should describe option (of putting something new) as well.

JS: that would make sense.

CB: what's the cost?

JS: 2 new unprotected attributes. old ones deprecated. New tags would need to be defined.

CB: +1 for add new, deprecate old.

**From jabber:** 
Brendan Moran (BM): Does that require additional tag allocations?

kaduk@jabber.org/barnowl: Yes, new tags required

mcr: I prefer adding something new.  I think that almost nobody was using countersignatures (yet), but I think the cost of having a new thing is not high.

mcr: "The methods FOO1 and FOO2 were defined in rfc8152, and are deprecated. Please use FOO3 and FOO4 to replace them"

Russ Housley: Do we know hom much countersignature has been used?

francesca: we use it in OSCORE groupcomm

francesca: but we could update

francesca: it's not published yet

mcr: I agree that OSCORE groupcomm could switch if we make sure we do this quick.

### **HUMS**

* HUM1: Leave things alone and you cannot countersign COSE_Sign0 
  - **RESULT: Pianissimo**

* HUM2: Fix it so countersign COSE_Sign0 works correctly
  - make the full change which could break existing implementation 
  - **RESULT: Pianissimo**

* HUM3: Fix it by defining new alg and deprecating old
  - **RESULT: Forte**

MM: Do we do it in a new doc?

MCR: Strong agreement that we need to do this. Anything other than doing it in this document won't be helpful. Maybe we need IETF LC to make everybody aware.

MM: Doc needs to come back to the wg, Algs as well because it will require changes.

JS: Algs won't require changes.

BK: Not sure we can go for Internet Standard without 

Barry: if it's breaking changes you have to stay at proposed standard.

CB: I'd qualify this change as "fixing a bug". 

Russ: +1 on same document. We don't have implementation experience - cycle it as proposed.

Barry: few months as proposed should not be an issue.

MCR: so, if we go as PS, then after a period of time to collect interoperability experience, the IESG can do a status change?

BL: Yes, we now have a thing called a status change document, and we can do that.

MM: Will confirm on the list but: Define something new in this document. Status change to proposed standard.

* HUM1: Be aggressive on what is signed – all bstr elements
  - **RESULT: Piano**

* HUM2: Be constrained on what is signed – first and last bstr element
  - **RESULT: Pianissimo**

MM: Rough consensus in the room to be aggressive. Will take it to the list.

## 2. Cert Compression (Joel Höglund) - 10 minutes (13:20 - 13:30)
  * https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-01

review of comments on the list, Issuer compression issues.
but ran out of time quickly after slide 13.

MM: Further comments on the list. If you have more algs tell Jim on the list.

**-- meeting adjourned 13:54 --**

Did not make it into the meeting:

## 3. More Algorithms (Jim Schaad) - 5 minutes (13:30 - 13:35)
  * https://tools.ietf.org/html/draft-schaad-cose-more-algs-01

## 4. Chartering (Chairs) - 15 minutes (13:35 - 13:50)
  * (WIP) https://github.com/cose-wg/Charter/blob/master/Charter.md


----
* [JS]: Jim Schaad
* [MM]: Matthew Miller
* [IP]: Ivaylo Petrov
* [BK]: Benjamin Kaduk
* [GS]: Göran Selander
* [CB]: Carsten Bormann
* [MCR]: Michael Richardson