Notes from COSE
===============

Justin presented what COSE is about. Group chartered two months ago. Kepeng Li and Justin Richer presented themselves. COSE will interface with CORE, ACE, others.
JSON to JOSE as CBOR to COSE
Signing/validation, encryption/decryption, key (public or private) representation
Out of scope: key management, identity management, stuff JOSE did not do.
Mike Johns (Microsoft): what kind of key management is out of scope?
Targetting constrained environments.
Different constraints: memory, power, network usage.

Justin: always have to think "What Would Jose Do?" Not necessarily copying everything, but have to have good justifications. We need to understand what parts of Jose work, and what is actually in use.

Göran presenting on requirements. DTLS protects information flow, COSE protects data objects. All proposals on the table use both, so a "thing" will need to implement both.
Push scheme / client pull scheme
Object Secure CoAP (OSCOAP)
draft-selander-ace-object-security-02
Wraps a CoAP message in a secure message format
header consists of alg, context identifier, sequence number
payload mode: the payload is wrapped as a secure message (SM), so the CoAP payload is replaced with SM.
Mode:CoAP: protects the entire CoAP message.
Sean Turner: Happy with this. except the size. Want to make sure we do the right thing and that it's not 25 bytes too big.
Justin: there is a broad world of constrained devices, each with different constraints. 
Kathleen: What size device are we going to aim for?
Thomas W: available payload of 90 bytes.
Carsten: What class we are addressing depends on what kind of crypto we're using. Some crypto requires more power.
Hannes: (responding to Thomas) not sure frame size is what we should be shooting for. They have adaptation layers. 
Thomas: we have three of four layers of fragmentation. But the more you use the less constrained you can be.
Justin: UDP frame size is a good metric.
????
Göran: context identifier is unique

Mike Jones presenting on Key Issues and Choices for COSE

Keep simple things simple. Optimize for compactness (of representations and of implementations)

No comments in the room.

Jim Schaad on COSE Message Draft
Jim: COSE should not have MTI. This should be determined per-applications. JOSE has MTI algorithms because we were going to work only in a browser. (Justin shakes his head)
Justin: can be separate documents. Our deliverables can be spread out onto >1 docs
Carsten: split off algorithms from core document. But might cause a hard-to-release cluster of documents. We should make sure that the documents don't stick. 
Sean: for two specs: one for core, one for algorithms. Then we can rev the algorithms separately. Not too many documents but base should be algorithm-independent.
Kathleen: Want to avoid the duplications in multiple document. So start with one and split it out if needed. 
Justin (from the floor): I hated JWA as a separate document. You had to get both the JWS document and the JWS part in JWA. I prefer to have it in a single document and add the agility.
Yaron: FWIW: You want to have MTI for interop tests.
Mike Jones: We're not going to update the algorithm drafts. We'll add new ones or deprecate old ones in new drafts.
Jim: Do die-die-die specs update the old specs
Sean: no. It's also not an important thing. Fine with having two.
Mike Jones: Agree with Jim that it's up to applications what part to implement: algorithms, recipient, only signing, only verification. We said that in JOSE as well.

Carsten: in CBOR we started with JSON, which has only an unordered map and array. Look at the number of 'if' statements in your implementation. 
Justin: that assumes stream-based processing rather than object-based
Carsten: you have something between them. Just looking at the bytes it's helpful if parts that have a defined structure there is one way to encode it. (? - not clear I got that right)

Jim: are maps a better thing to have in this space? I don't think anyone is going to argue for that.

Sean: ACE did the high-medium-low thing. 
Carsten: RFC 7228 is the reference
Jim: AEAD algorithms: AES modes (GCM, CCN, OCB)  ChaCha+Poly?
Jim: suggest CCM (because it's specified in many places) and GCM.
(nobody loves 192 bits. 128 and maybe 256 for the future)
Thomas W: tag length. CCM uses 32-bit tag/mac. 
Jim: I said 8 bytes, not 4. I didn't see anything using 4 octet.
Hannes: different specifications use different tag lengths. 8 is truncated from 16. DTLS uses a truncated version. 
Jim: OCB is a "hot" algorithm. But IoT world is not interested (need a decrypt function). ChaCha is not currently in hardware. Can avoid them for the moment.
Hannes: some want ChaCha. Different specifications use CCM differently, so reuse is hard.
Rick: OCB might have an IPR issue.
Mike Jones: why eliminate the composite algorithm? (AES-CBC + HMAC)
Jim: not used in the IoT world at all.
(Jim talking about MACs)
SHA-3 not yet finalized, but will be usable with or without the HMAC constructions.
(Key management methods)
Justin: want interop
Jim S: on the GitHub site there is a C# and partial C implementation, also test vectors. Try to get those updated. Will send pointer
Carsten: in my site I collect implementation. Currently CBOR.
Mike Jones: several proposals such as using arrays at the top level. How do we discuss them
Jim: will send questions to the list. Haven’t done so the last month, but will.