Minutes interim-2021-cose-02: Wed 16:00
minutes-interim-2021-cose-02-202102171600-00

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

## Connection details

* Date: February 17, 2021
* Time: 08-09 Pacific, 17:00 CET:
  https://www.worldtimebuddy.com/?qm=1&lid=8,12,100&h=8&date=2021-02-17&sln=8-9&hf=0
* Meeting link:

* Slides link:
  https://datatracker.ietf.org/meeting/interim-2021-cose-02/session/cose

# Attendees

* Ivaylo Petrov
* Matthew Miller
* Francesca Palombini (not in webex)
* Peter Yee, AKAYLA
* Göran Selander
* John Preuß Mattsson, Ericsson
* Jonathan Hammell, Canadian Centre for Cyber Security
* Laurence Lundblade (not in webex)
* Carsten Bormann, TZI
* Joel Höglund
* Marco Tiloca, RISE
* Ben Kaduk, AKAMAI
* Michael Richardson, Sandelman Software Works
* Stefan Hristozov, Fraunhofer AISEC
* Russ Housley, Vigil Security
* Rikard Höglund
* Henk Birkholz, Fraunhofer SIT

# Action Items

* Chairs to merge Charter's outstanding PR and submit to Ben to move forward
* John Mattsson to provide starting information for x509 trust discussions
before IETF 110 * John Mattsson to provide text lifting restrictions about
using PKCS7 * Ben Kaduk To check what are the options for
draft-ietf-lwig-curve-representations-13 (short labels)

# Minutes

## 1. Administrivia (Chairs)
  - Note Well
  - Blue sheets (in the minutes)
  - Minutes: https://codimd.ietf.org/notes-ietf-interim-2021-cose-02-cose?both
  - Jabber: cose@jabber.ietf.org
  - Agenda Bartering

## 2. Update on drafts status and charter (Chairs)
  - hash-algs
  - rfc8152bis-algs
  - rfc8152bis-struct
  - Counter-sign - last call result
  - x509
  - rechartering

## 3. x509

* 'x5u' Protected parameter?

Ben Kaduk: We are trying to reverse engineer why this text was written, and if
it might be safer to make a clean analysis from the start.

Russ Housley: There are two ways you can get back a cert the sender did not
intend
   1. The URL is changed by a MITM, which the protected header protects against
   2. The server delivers up a different cert than the sender intended, which
   there is no protection from today

Michael Richardson:  I don't understand this statement, and don't think there
is any value of being in the protected header.

John Mattsson: There might be value in protecting identities, this is probably
something we need ot have a discussion about again

Carsten Bormann: Normally, COSE X.509 certificates just divulge information to
the recipient. (1) What is the consequence of the wrong information being
divulged?  Like any certificate, this one needs to be validated under the
authorization policies. (2) What is the security objective of protecting it? 
Integrity?  Confidentiality?

RH: Pretty sure this was integrity

Henk Birkholz: What are we losing by making it unprotected, and it getting
stripped out?

JM: You might want protection if someone borrows your public key and inserts
their own identity (see SIGMA)

Ivaylo Petrov: Sounds like we need to step back and discuss the attacks, would
someone be able to lead this discussion?

BK: Would John be willing to lead it?

JM: I can try to provide something

IP: Note there are others interested in this work, but that doesn't mean we
rush things.

HK: I agree, and while not rushing or pressuring, we should move this along.

CB: Does providing a cert in the x5u position give this any special semantics
to be used by the recipient? (Or is the trust relationship in Jim's text just
about trusting the provider of the x5u certificate to actually provide it,
i.e., an availability objective?)

BK: important to note (if not already) that the recipient could initiate an
outbound connection, which has security and privacy considerations.

Jonathan Hammell: This outbound connection trigger could inform others that the
message was received.

IP: We can wait for John to dig a little deeper and discuss at the IETF meeting

CB: The requirement for providing (D)TLS, there is clear understanding of how
you get from the URI text string in the URI authority to the x509 content (the
security communication expectations), and OSCORE does not define that today.

JM: Wondering why PKCS7?

RH/MR: This is what's commonly called P7C, cert only

IP: I hear that we should not be mandating only PKCS7 and leave possibility to
have other formats?

JM: I think that would be an easy/quick fix (and addresses Michael's problems),
and can provide text

JM: Regarding headers/tags, consider mandating x5chain format

JH: The formatting is similar for x5bag and x5chain, but if there's a single
component it's a bstr while multiple is an array, but this is different

JM: Yes, this is defined as a sequence, so even a single cert needs to be
wrapped in an array.

CB: You are referring to the CDDL representation?  What you see on the wire is
a "naked" bstr, or a CBOR sequence of such naked bstrs

JM: You have a unique encoding, but there are questions about interop with
other CBOR libraries, that we need to get back to.

## 4. AOB

### 4.1 IANA COSE Registrations (Göran Selander)

JM: For EdDSA, the hash algorithm is determined by the curve

JM: I think several of Curve25519 have co-factors, but it's RFC 6090 with
co-factors

BK: Not a substative comment, but it seems a potential issue if the procedures
for multiplying by co-factors are buried in the curve, and maybe could miss the
details (but it's speculative and I don't have any specific problems to point
to)

Göran Selander: Would adding more point alleivate that?

BK: I'm not sure it would

HB: Could it be that the details are so buried away that implementers are
likely to miss it? I am leaning toward more transparency.

BK: Option 2 is more robust, but it also adds to every document on curves needs
to be very clear; while option 1 requires a single document be very clear.  We
could lean on Expert Reviewers to point this out before a registration is made.

GS: I hear a preference for Option 2

BK: There will be a big bikeshed for what the short name is, since you need to
fix the output of SHAKE

GS: Is this something that COSE should take as work (currently part of lwig
curve registration draft)?

BK: This is totally in scope for COSE, and it's totally ok to ask the group
working on it to fix it up.  The most expedient seems to be to request changes
in lwig's document.

BK: I had started to look at this, and my tentative conclusion is that we stay
true to 8152, and ECDSA uses the two-point format; otherwise we'd need to
update 8152 again