Connection details ------------------ * Date: February 15, 2019 * Time: 10-11 Pacific, 19:00 CET: https://www.worldtimebuddy.com/?qm=1&lid=100,5392171,212,6&h=100&date=2019-02-15&sln=18-19 * Webex Recording Link: https://ietf.webex.com/ietf/ldr.php?RCID=5bed4c9e1dad64b94e647a693486381c Attendees --------- * Ivaylo Petrov * Matthew Miller * Jim Schaad * Justin Richer * Carsten Bormann Action Items ---------------------------- - Start discussion on countersignature issues (three items) (Chairs) + Allow for distinguishing one vs many countersignatures? + Change context value from “CounterSignature0” to “CounterSignature1”? + CBOR Tag for CounterSignatures? - Call-for-consensus to to split X509 and hashes (Chairs) - Start discussion on using X509 certs as keys (Chairs) - Review RFC8152bis IANA considerations rewrite + Contact Designated Experts for opinions (Jim) - Start discussion on supporting older algorithms (Carsten) - Request additional reviews of draft-ietf-cose-suit-hash-sig (Chairs) Minutes ------ [19:07] Administrivia - Matthew Miller * Presenting Note-well * Agenda bashing * Presenting charter - 5 deliverables [19:10] status of 8152bis docs - Jim Schaad * Errata are corrected * Still some questions - On countersignatures - we currently cannot distinguish one vs many looking only at the top level tag. Do we want to change that? - we can have coutersignature that only has signature, whereas normally we also have context - probably no implementations will be affected if we include context as well. - should coutersignatures be in their own topic? Currently some parts are in a subsection of signatures, some are in appendix. - should a ocuntersignature have its own CBOR tag, so that it can live on its own. Maybe we can wait until someone asks for it. Jim: Opinions? Justin: For now I don't have an opinion. MM(as individual): For me we can wait until someone asks about CBOR Tags, but we should raise it on the ML. And for the other part, it would rather move it up. MM: Speaking as chair, we should bring this to the list. Should we bring them up separately or all in one. Justin: From process point of view, better to split them at least on 3 different items. MM: We as chairs will start a discussion on those points. Jim: Rewrote the IANA considerations after the work has already been done, so if there are any comments, the sooner, the better. Carsten suggested to change some of the expert considerations, but for me for the algorithms at least I don't see the need, but given that I have written those things, maybe I am not the best person to say. No idea if there have been any issues on the other registries. Maybe we should send an email to the ML or to the ADs. Jim: CDDL is left alone, I have just put a reference to the document and in the text we have a subset of it. The reason is that I don't want to have a normative reference to a document that is not going to be standard any time soon. Jim: Down reference to STD track doc RFC 7049 (CBOR) MM: It is not a down reference yet. Jim: It is the moment we decide to go full standard, because that document is a proposed standard, not a full standard. They have a -bis document that they will try to get to full standard. MM: For IANA considerations, as long as readers and IANA understand it, no problem. We can ask for review specifically for this section. Jim: I don't think IANA will have a problem if we make their life easier. Given the effort we spend the first time. MM: I can understand, especially having experience with documents that invalidate some registries. Jim: Still having pointers to the different registries. MM: As for the experts, lets contact them and see if the criteria still apply and what they think. Do you want the chairs to do that or you can do that. Jim: I can do that. MM: Let the ML know for the results afterwards. MM: As for the rewrites, lets see what the ML thinks about it. MM(individual): I don't like duplication, but given that it is a self-contained document, I don't think it's going to be a problem. For the Down reference, let's contact the ADs. Jim: We should definitely call out to them, but I don't think it's going to be an issue. [19:24] Algorithms: Jim: If we add new algorithms, that might slow down both documents, as both of them obsoletes the old one. Right now we have padded KeyWrap with AES (personally not very happy). Other people are doing SHAKE. Do we want to open to use more hash algorithms? Do we need a charter change in order to do that? Are we asked for more things to add? SUIT is asking for 2 things. Justin: Speaking as previous COSE chair. The first time around, we had a big push-back against splitting into too many pars from developers because JOSE experience with multiple parts made it difficult to implement. I believe that was a good decision. I see interest for new algorithms to be added as separate documents. I don't think the structure should stay on its own, but I think it might be a good idea for new algs to be on their own. It was a mistake to have JWA apart from JWS, etc. Old algs should stay in the rewrite. I would be happy to answer any questions from the current chairs. MM: We asked if the split documents are acceptable during the adoption. I do understand (as individual) the JOSE side of things. We can bring this question back to the ML, but given that no one that responded on the call for adoption supported keeping them together, I am inclined not to do that. We as chairs can talk to the ADs. Justin: Other WGs can add to the algorithms was meant as it is clear that the current WG is not going to be the end state of the algs for all time. Jim: The questions is whether we add them to the current document. Justin: I would say - we have the new algs in a separate document, but I would prefer the algorithms not to be split from the old document. This is a personal preference. Jim: SUIT asked for AES-KW padded - they intend to use it for content encryption, not key wrap alg. I have a few problems with that. It is an AE not AEAD. It is not clear to me whether it has better security than AES-GCM. Difference is that not all the bits effect every bit in the encryption result. Jim: I was hoping to decide the question during this call and have a new version before the draft submission deadline. MM: I think that schedule might be too aggressive, but for me the biggest question is for the algs. Jim: I think the biggest question is about coutersignatures, if all algorithms go to a new document then algs is basically done. [19:38] X509 certificates: Jim: No that far off, as no one has played too much with it I believe, but I have added some hash functions, because I needed them. There is a question about which hash funcs we would need. ed448? Truncated version of SHA-256. Currently I don't have putting certs in COSE_key object, as when I was trying to specify it, it seemed difficult, but I have not spoken to implementers. Justin, do you know if this has been an issue in JOSE. Justin: The certs are added as strings, not as structure. Jim: Right, but there were questions about ensuring that fields such as keys are consistent Justin: That is a post processing requirement. There are couple of libs that enforce it (namely nimbus?). Having multiple representations of keys in the same struct could be handy, but it can cause problems with validation. Jim: I was thinking about having either a COSE_KEY or an X.509 certificate Justin: This sounds as a reasonable approach. Using COSE as user, not implementer. Having done impl of JOSE - there might be some wisdom to that. The problem is that x509 represents an auth chain, whereas web keys and COSE keys represent only the keys themself, so there is difference between the two. Jim: An X.509 certificate is more like a JWT or CWT MM: As individual, I can see problems on both sides. On one side the size might explode, on the other interoperability might suffer. This would be an interesting question to the ML. Jim: We need to have semi-stable version of the hashes before we can do early registration request. Jim: How much should chairs deal with that. MM: I think we need a document for the hashes themselves, if we are to split them. We will need to discuss this internally and with the AD. Carsten: One of the customers is SUIT. They want numbers soon. Jim: I think they want the numbers right now for prototyping purposes. Carsten: I don't see why to delay providing those numbers. MM: How quickly do you think we can do the split? Jim: I can have that tomorrow. MM: I think we should bring this to the ML and we can do that immediately. We can have a consensus for the split as acceptance for adoption. Jim: So I need to create a hashes draft that will be proposed for adoption on the ML and if accepted will implicitly mean removing from the x509 document. MM: Yes. Carsten: For new things people will be using COSE, but for old things they will be using old algs, so they would like to include some old/slightly broken algs. How friendly are we to older algs. Jim: How old? Carsten: One person mentioned SHA-1, but I don't think I should bring that in this context. There are places where those hashes exist and not being able to name them. Jim: If we are talking about doing a signature with SHA-1, There might be some in the RSA document that Mike Jones did Carsten: I am not talking about x509 with SHA-1, I just wanted to mentioned that they want to have a way to express their stuff in COSE primitives. MM: Carsten, could you detail that and present it to the ML in order to have a more informed judgment. Carsten: Where do we do concise IDs? I would say here. MM: Yeah... Jim: Interesting question. I think we should sit with Henk, chairs, you Carsten, at least one AD and discuss this. Maybe ACE? Carsten: Maybe CORE. As long as it is just profile for CWTs we can do it in CORE. If we start inventing other things, we can not do it in CORE. MM: We are not chartered for it, so we will have to discuss it in a broader context. Carsten: The reason this came up now is that the trans? WG need it and we can do something about them, but we would need to accelerate that MM: Jim, can you sent the list, so that we can discuss it. MM: suit-hash-sig is stable and ready for review according to Russ. Jim: I will definitely review it. MM: Maybe it is not ready for WGLC and we can not have a LC before the -bis documents are ready, but that review will be very helpful. We will ask on the ML for further reviews. MM: webauthn drafts - they do need work. We would like to combine them. We would like to do call for adoption during Prague. If there are any objections, please let us know. Jim: I have a concern. The RSA algs have an early registration on them that dated from I believe May. After 1 year you can renew it without any problem, but after 2 it needs IESG approval. There has been some security concerns that might cause discussions that can take longer time. MM: That is a good point. Other concerns? Carsten: That might be an example for taking algs that are not that great or make them to something ??? MM: Those docs are not very urgent, but with the early registrations that might be a problem, so we will check with Mike Jones and bring this back to the ML. MM: The last question was whether we will have a new virtual interim before the IETF 104. Given the low participation, I am inclined to wait for the IETF 104. Jim: Given the deadlines, I don't think we would need one. Carsten: Maybe the time was not very appropriate for people in Europe.