Minutes interim-2019-cose-01: Fri 19:00
minutes-interim-2019-cose-01-201902151900-00

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. <Carsten joins> 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.