Minutes IETF110: cose
minutes-110-cose-00

COSE IETF 110 - Virtual/Meetecho
================================

# Connection details

* Date: March 12, 2021
* Time: 06:30 Pacific, 15:30 CET:
  https://www.worldtimebuddy.com/?qm=1&lid=100,12,8&h=100&date=2021-3-12&sln=14.5-15.5&hf=1
* Recording link:
  https://youtu.be/a73GiqfA9Do?t=125
* Slides link:
  https://datatracker.ietf.org/meeting/110/session/cose

# Action Items

- [Chairs] set up interim meetings
- [Goran?] On IANA registration policies - adjectives about recommended vs not

# Minutes

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

Chair: Michael Jones taking Matthew Miller's place

## 1. Document Status (Chairs)

Ivaylo summarizing (see slides)

  * 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/
      * please contribute any thoughts on whether it updates bis-struct or
      RFC8152
  * https://datatracker.ietf.org/doc/charter-ietf-cose/ (IESG discussion ~2
  weeks from now)

IP: Interim meetings in future? Were useful in the past.
(Jabber: CB und JPM +1 to continue)
MJ: Cadence?
CB: Were not freequent enough, but depends on whether there's active
discussion. CBOR encoded certificates will be active for some time, then we'll
need more frequent ones. Then, we can reduce frequency. MCR (Jabber): 2 weeks
good for me, too frequent for others JPM: maybe every month HT: every month
Goran: at least one IP: Maybe schedule 2 weeks[?] and cancel on demand; also
discuss on list then. BK: Good input, chairs can make concrete proposal and get
confirmation on the list.

## 2. x509 draft discussion
  * https://datatracker.ietf.org/doc/draft-ietf-cose-x509/

JPM presenting (see slides; summarizing github issues, list issues and last
interim -- all made into one PR)

IP on p4: We reference EDHOC; should this be a reference if we keep the text
like that? JPM: Text doesn't need to refer to examples (and then there's no
references either) BK on jabber: +1

HT on p5: What are the main use cases? Document specifies many ways to pass
X.509 of different types around (like here with the bag). Depends on what use
case you try to cover which cases you need. Concrete problem: Laundry list of
things, implementations become incomplete. What are use cases, are you
implementing them? JPM passing the question on (being in more of an editorial
role here)

GS: There was the question of phrasing this -- MUST for integrity protection or
just POP. Otherwise complicated for anyone to comply with. GS: Previous slide
had discussion on example mentions. Here we mention EDHOC -- it's motivated by
being example of how COSE is used in a security protocol (as opposed to p4), so
it's reasonable.

[note taker note: not getting everything that's happening on jabber]

BK on p10: There is good support for a more specific media type on the chat.
CB: HT on Jabber said to rather not mention EDHOC because it'd be adding a
reference late, rather use more general terminology. GS: Important part is to
provide something for external AADs. HT: Just notice EDHOC being mentioned 5x
is overselling it. JPM: It's more or less the same text four times. HT: I
should be independent of these protocols, independent of what the next favorite
thing is. There will be a continuing list of protocols. GS: Don't mind leaving
out specific protocols, but there we should not leave out explaining the value
of having certificates in the AAD. JPM: Can be removed. HT agreeing with GS.
JPM: And remove TLS? HT: And IPSec.

## 3. Certificates CBOR encoding
  * https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-08

JPM presenting (see slides)

HT: Have been co-authoring on CWTs used in TLS, how do those compare
considering that they are both COSE [...] JPM: C509 are not COSE. Two types
here: compressed X.509 (just compressed; [?] certificate type in TLS). The
other is natively signed C509 certificate. Difference is whether signature is
over DER or over CBOR -- but no COSE in either. HT: Draft name was "compressed
X.509 certificates". Feature is you can use existing X.509 certificate and
compress on the wire. Downside is that you still need X.509 in the libraries.
Then scope is changed and still in the same document? JPM: It was already in
the original document. Draft name is still "compressed", will change that at
adoption time. Term is already gone from the body. It now already registers a
certificate type. Then will go to TLS WG and ask about whether they want this.
(And where it's best done). HT: Had discussion earlier in TLS and there the
emphasis was on compression feature, that's why I was confused. JPM: COSE
discussion was about whether that would be standardized or not; now conclusion
was that most interest is in native. Comparing to CWT -- CWT is more flexible
and new. [...] HT: Was the native part implemented? JPM: No, so far just
compression. Working on that, soon to be done and to be open source. Inverse
planned too.

HT on p11: Rich's document talks about server authentication on the web. This
here talks about client authentication of IoT devices. Should the use of ? on
the web for servers also apply to clients on the IoT?

## 4. IANA registrations policies (tentative)

GS: Guidance requested from WG -- see slides.

BK: Seems this is something we should allocate code points for, especially as
COSE is a framework and not a protocol. Question is more of whether we want to
change structure of registry to have a warning label for them. GS: We have
"recommended" column, which could be "yes", "no", "deprecated" IIRC. Is "no"
sufficient in this case? MJ as individual: The JOSE registry has some things
registeres as being "prohibited", that categorization could be added again.
There may be legacy reasons to reference that as an algorithm. I'm good on
adding code points, "recommended" vs "not recommended" is not strong enough. If
we do this for legacy stuff, we should add "prohibited". GS: Would that be same
column? MJ: Same column, more values. GS: Fine by me. BK on Jabber: tossing
more adjectives.

GS: So go to mailing list and decide there how to respond.
HT: What do you mean by that?
GS: Take off-line, only 1min left

## 5. AOB

GS: On RPKs.
GS: Several requests to define COSE header map for RPK, eg. as it's required in
LAKE WG and other settings. Question: Do we need a separate specification? How
should we manage that w/rt 7250? Any quick comments? Define it in analogy to
7250 or just as another COSE header map? HT on jabber: It's already in COSE_Key
GS: Compare to X.509, we have COSE header map to index whether this is x5t or
x5chain; a similar type is what I'm requesting.

[see lots of chat on Jabber]

HT: Name of draft?
GS: Was just proposed, no draft yet.

Rene Struik: I've requested COSE registration in lwig-perf draft, wondering how
to speed that up to get to resolution. First round took months without
satisfactory results. How to make it seem more collaborative? Currently we have
offline expert review. Discussion should be on technical merit. BK: Have
partial review of draft. RS: More a general question. How can process be better
at getting results? GS: I've answered IANA point a month ago. RS: After 3
months of silence, where it seems people are interested in blocking things than
moving forward. BK: If there's issues with non-responsive take it to IESG. RS:
[?] Should have discussion on technical merit, not on political [?]. BK: There
were issues raised that did not get follow-ups, so there's work on many fronts.
RS: Want things to constructively go forward. BK: Agree on focusing on
technical, but not recall any political posturing.

Thanks to Matt as outgoing WG chair.