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