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.
- [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
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.
- [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.
- [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.
- [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.