COSE Virtual Interim
====================

## Connection details

* Date: October 12, 2021
* Time: 08:00-09:00 Pacific, 17:00 CEST:
  https://www.worldtimebuddy.com/?qm=1&lid=8,12,100&h=8&date=2021-10-12&sln=8-9&hf=0
* Meeting recording:
  https://youtu.be/XUg3W7VIIx0
* Slides link:
  https://datatracker.ietf.org/meeting/interim-2021-cose-06/session/cose
  

# Attendees

* Ivaylo Petrov, Google
* ~Mike Jones, Microsoft~
* Peter Yee, AKAYLA
* Göran Selander, Ericsson 
* John Preuß Mattsson, Ericsson
* Carsten Bormann, TZI
* Rikard Höglund, RISE
* Marco Tiloca, RISE
* Russ Housley, Vigil Security
* Michael Richardson, Sandelman
* Sean Turner, sn3rd
* Francesa Palombini, Ericsson
* Matthew Miller,

# Action Items

  * [Ivaylo]: hash-algs followup
  * [Ivaylo]: merge pr #35

# Minutes
## 1. Administrivia (Chairs)
  * NOTE WELL
  * Bluesheets
  * Jabber + Minutes
  * Agenda Bartering

## 2. Document Status (Chairs)

  * https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/

  * https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/

  * https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/

  * https://datatracker.ietf.org/doc/draft-ietf-cose-countersign/
 
  * https://datatracker.ietf.org/doc/draft-ietf-cose-x509/


## 3. x509

Certs in protected?
- [Carsten Bormann] - certificates already have integrity protection; only when changing the recipient is this need to be very very explicit.
- [Russ Housley] - Concern is when multiple CAs have the authority over the name, which is what RFC 2634 is concerned about.
- [John Mattsson] - Should always protect the cert; either put the x5t or the CA cert in protected.

* Action: place x5t/x5chain/x5bag in protected header.

media types?
- [CB] - Current implies either you have a chain or a bag.  Is this true (e.g., bag of one, chain of another)?  Don't want media types for all the possible structures; could make one media type and have structure indicate whether it's a chain or a bag/tree.
- [JM] - Would be fine with a single media type, but how to signal the structure?  CBOR tags?
- [CB] - That would work.  But struggling with use-cases.
- [JM] - The media type should align with headers -- either multiple media types or a single and an explicit signal.
- [Chair] - can we move this to the next draft?
- [CB] - Can't move it all to the next draft, or it's empty!
- [JM] - Do we need to support both bag & chain, or is just one enough?  If both, then what about media type?
- [CB] - Could define media type now and parameters later.  Media type would just be the CDDL at the end of Section 2.  Hard to define when there are not good use-cases to guide.
- [chair] - Not sure how to obtain those use-cases.
- [CB] - Cleanest is to have a media type COSE-x509-certs, and have some slightly expanded wording that one the order matters, and the other does not.  Is there an existing PR?
- [JM] - I think it's in the same PR (#35) [this is a monster PR]
- [CB] - Let's have a small PR for just this.  I'll work on it

* Action: merge PR #35 now
* Action: Carsten to create PR for adding a media type and light language on differences

## 4. Göran's slides

`kid` to int (PR #34)
- [RH] - What happens if one issues an int and the other a bstr?
- [JM] - Same as would happen for alg or kty.  Need to handle identify by bstr or int.
- [RH] - SPKI and Authority pubkeyinfo are octet strings, so think this was bstr to account for that/
- [JM] - Did not know this was to be the SPKI; thought this was just an identifier.
- [RH] - You're probably right.  I don't object, but if it has the intent to carry SPKI, this could be a problem.
- [JM] - Would you need to convert?
- [CB] - Usually use kid to look up.  if you use a string, then look up to a string; if by integer, look up by int.  Think chance of confusion is limited.
- [RH] - Convinced this is not an issue.
- [Francesca] - Process-wise, need resolution (WGLC? IETF LC?) since draft is in AUTH48?
- [RH] - RFC Editor  will ask AD to sign-off; if AD is comfortable, then it's fine.  Otherwise another LC.

* Action: Göran to follow up with Ben Kaduk about change process (cc cose-chairs)

C509
- [CB] - Timeline?
- [Göran Selander] - looking for feedback by next meeting.  Need a little more discussion on the total content (CSR? CRL? OCSP? etc).  Needs review.
- [CB] - Is there a charter issue? Should this be in a separate doc?
- [GS] - No, think that's allowed.
- [JM] - Lack of progress is lack of reviews _and_ lack of time.
- [CB] - Doing all that is not trivial; doing it in the separate draft is fine.
- [JM] - Revocation could be a in separate doc, and CSR (??) kept here.

CWT
- [CB] - how do you verify a CWT?  Is it all known, or to recurse?
- [GS] - Handle like x509.
- [CB] - Can this be a separate draft?
- [GS] - Yes, it should be.  Gauging interest in this support.
- [CB] - How does TLS deal with this?
- [JM] - TLS has its own format.

* no enthusiasm, but might be needed in future.

x5*-sender usage
- [GS] - why was this restricted to static-static?
- [RH] - Ephemeral is never certified, so this isn't really need for that.
- [JM] - Why two separate parameters?  Why for x509 but not kid?
- [RH] - If trying form the shared secret, both might be certified.  In Static-Ephemeral, only one is certified (the ephemeral is sent inline)
- [JM] - Could do static-static with just key parameters. If you can't do it with two x5t parameters, why can you do it with 2 kids?
- [RH] - Just need a way to identify which keys are involved.  Two kids could be fine if they properly identify.  Two x5t's could also.

* Action: none

## 7. AOB