Minutes interim-2021-cose-06: Tue 17:00
minutes-interim-2021-cose-06-202110121700-00
Meeting Minutes | CBOR Object Signing and Encryption (cose) WG Snapshot | |
---|---|---|
Date and time | 2021-10-12 15:00 | |
Title | Minutes interim-2021-cose-06: Tue 17:00 | |
State | Active | |
Other versions | markdown | |
Last updated | 2021-10-26 |
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-countersign/
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