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