Subject: [Cose] Are we finished with the charter?

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Apr 2015 14:17:39 -0700

There have been no messages for a few days; maybe we are done. Mike wants something about a JWK mapping, but I don't see any other support for it.

Oh, and you need to change "March" to "April" below because we already ran through that...

Time to submit it to Kathleen?

--Paul Hoffman

> On Mar 29, 2015, at 8:11 AM, Kepeng Li <[email-masked]> wrote:
> 
> Thanks for the input.
> 
> Based on the discussion, now the draft charter 2015-03-29 is:
> 
> # CBOR Object Signing and Encryption (COSE)
> 
> ## Charter for Working Group
> 
> Concise Binary Object Representation (CBOR, RFC 7049) is a concise
> binary format for the serialization of data structured to an extended
> version of the JSON data model. One motivation for CBOR was to make
> this data model more amenable to constrained nodes and constrained
> node networks (RFC 7228).
> 
> The JOSE working group recently completed producing representations
> for message authentication (MACs), encryption, and digital signatures,
> using JSON representation. This working group will reuse the work
> done by JOSE, adapting it to the capabilities of CBOR. This will rely
> on the JOSE registries, which, where this provides additional
> efficiency, will be expanded with additional information.
> 
> The resulting formats will not be cryptographically convertible from
> or to JOSE formats. This lack of a need for bit-for-bit compabitility
> which will enable some simplification in the adaptation process.
> 
> The WG will have two deliverables:
> - a standards-track specification covering the same cryptographic
> formats from JOSE, expressed in CBOR;
> - registration for algorithms (such as AES-CCM-8) that are appropriate
> for constrained environments.
> 
> The Working Group will use a wiki to track desired use cases for its work,
> but does not intend to publish this as an RFC.
> 
> ## Milestones
> 
> * March 2015: Submit COSE specification as a WG item
> 
> * April 2015: Submit COSE constrained-appropriate algorithms as a WG item
> 
> * June 2015: Submit COSE specification to the IESG, for publication as
> a Proposed Standard
> 
> * July 2015: Submit COSE constrained-appropriate algorithms to the
> IESG, for publication as a Proposed Standard
> 
> I will put the draft charter to a wiki page, so we can track changes from that.

---

From: ⌘ Matt Miller <[email-masked]>
Date: Wed, 1 Apr 2015 15:26:19 -0600

On 4/1/15 3:17 PM, Paul Hoffman wrote:
> There have been no messages for a few days; maybe we are done. Mike
> wants something about a JWK mapping, but I don't see any other
> support for it.
> 

What I saw is Mike effectively asking "what about JWK?" and Carsten
replying "It was implied".  I do think it is necessary to have the
correct CBOR representation of keys.  I also think the mapping is
fairly trivial -- where the value was base64url, it's now bstr.

To accomplish that, I suggest changing the second paragraph to include
mention of "cryptographic keys":

- -----NEW TEXT-----
The JOSE working group recently completed producing representations
for cryptographic keys, message authentication (MACs), encryption,
and digital signatures, using JSON representation. This working group
will reuse the work done by JOSE, adapting it to the capabilities of
CBOR. This will rely on the JOSE registries, which, where this
provides additional efficiency, will be expanded with additional
information.
- -----NEW TEXT-----

Otherwise I think it looks good, and is ready to submit.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

>> Concise Binary Object Representation (CBOR, RFC 7049) is a
>> concise binary format for the serialization of data structured to
>> an extended version of the JSON data model. One motivation for
>> CBOR was to make this data model more amenable to constrained
>> nodes and constrained node networks (RFC 7228).
>> 
>> The JOSE working group recently completed producing
>> representations for message authentication (MACs), encryption,
>> and digital signatures, using JSON representation. This working
>> group will reuse the work done by JOSE, adapting it to the
>> capabilities of CBOR. This will rely on the JOSE registries,
>> which, where this provides additional efficiency, will be
>> expanded with additional information.
>> 
>> The resulting formats will not be cryptographically convertible
>> from or to JOSE formats. This lack of a need for bit-for-bit
>> compabitility which will enable some simplification in the
>> adaptation process.
>> 
>> The WG will have two deliverables: - a standards-track
>> specification covering the same cryptographic formats from JOSE,
>> expressed in CBOR; - registration for algorithms (such as
>> AES-CCM-8) that are appropriate for constrained environments.
>> 
>> The Working Group will use a wiki to track desired use cases for
>> its work, but does not intend to publish this as an RFC.
>> 
>> ## Milestones
>> 
>> * June 2015: Submit COSE specification to the IESG, for
>> publication as a Proposed Standard
>> 
>> * July 2015: Submit COSE constrained-appropriate algorithms to
>> the IESG, for publication as a Proposed Standard
>> 
> _______________________________________________ Cose mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/cose
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 01 Apr 2015 23:43:31 +0200

Because things are getting confusing with all that mail back and forth,
I have tried to document the progress of the draft charter at

https://github.com/cose-spec/wg-charter/blob/master/draft-charter.md

Yes, I also think it is time to submit this to Kathleen.

On a separate note, I have also started to collect use case information
(read: put Göran's input into a markdown file).  Enjoy (and contribute) at:

https://github.com/cose-spec/use-cases/blob/master/use-cases.md

Grüße, Carsten

[No April Fool jokes were harmed in compositing this message.]

---

From: ⌘ Matt Miller <[email-masked]>
Date: Wed, 1 Apr 2015 15:48:33 -0600

On 4/1/15 3:43 PM, Carsten Bormann wrote:
> Because things are getting confusing with all that mail back and
> forth, I have tried to document the progress of the draft charter
> at
> 
Thanks for gathering it together, Carsten.

> On a separate note, I have also started to collect use case
> information (read: put Göran's input into a markdown file).  Enjoy
> (and contribute) at:
> 

I believe Paul said this before -- I don't think it's necessary to
formally publish a use case document.  I'm fine having something less
malleable (and more trackable) than a Wiki page, but I don't think
it's necessary to actual publish an I-D, let alone an RFC.

- -- 
- - m&m

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 01 Apr 2015 23:58:01 +0200

> it's necessary to actual publish an I-D, let alone an RFC.

Indeed -- that's why it's just a markdown file.

I'm much more interested in collecting input here than in polishing that
input into a freestanding document.
(Of course, if there is some confusing wording, we still may want to fix
it so we all know what the input was.)

I hope we can get other input.  (Unfortunately, not everybody is at
liberty to discuss every use case -- I know about a nice one from the
transportation world that I can't talk about right now.)

Grüße, Carsten

---

From: "Kepeng Li" <[email-masked]>
Date: Thu, 02 Apr 2015 12:13:39 +0800

>https://github.com/cose-spec/wg-charter/blob/master/draft-charter.md
Thank you Carsten, very helpful.
>Yes, I also think it is time to submit this to Kathleen.
Fine with me.
@Karen, Mike, Jim, Goeran and others, what do you think?
Thanks.
Kind Regards

Kpeng
------------------------------------------------------------------发件人：Carsten Bormann<[email-masked]>日　期：2015年04月02日 05:43:31收件人：Paul Hoffman<[email-masked]>抄　送：[email-masked]<[email-masked]>主　题：Re: [Cose] Are we finished with the charter?Because things are getting confusing with all that mail back and forth,
I have tried to document the progress of the draft charter at

Grüße, Carsten

_______________________________________________
Cose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cose

---

From: Göran Selander <[email-masked]>
Date: Thu, 2 Apr 2015 06:05:02 +0000

Regarding this formulation:

OLD
"a standards-track specification covering the same cryptographic formats from JOSE, expressed in CBOR"

What I tried to illustrate in the first set of use cases (thanks to Carsten uploaded to

https://github.com/cose-spec/use-cases/blob/master/use-cases.md)

is that the cryptographic formats provided by JOSE may not be sufficiently flexible to allow certain optimizations desirable for constrained devices, e.g.

  *   Detached AAD
  *   Support for specifying modes which allow integrity protection of other implicit data (EAD)
  *   Support for symmetric key encrypted and private key signed objects without double wrapping

Could we make clear that the work may include optimizations to JOSE? For example

NEW
"a standards-track specification covering the same cryptographic formats from JOSE and optimizations for constrained device processing, expressed in CBOR"

Best regards,
Göran

From: Kepeng Li <[email-masked]<mailto:[email-masked]>>
Date: Thursday 2 April 2015 06:13
To: Carsten Bormann <[email-masked]<mailto:[email-masked]>>, Paul Hoffman <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Cose] Are we finished with the charter?

Fine with me.

Thanks.

Kind Regards
Kpeng

------------------------------------------------------------------
发件人：Carsten Bormann<[email-masked]<mailto:[email-masked]>>
日　期：2015年04月02日 05:43:31
收件人：Paul Hoffman<[email-masked]<mailto:[email-masked]>>
抄　送：[email-masked]<mailto:送：[email-masked]><[email-masked]<mailto:[email-masked]>>
主　题：Re: [Cose] Are we finished with the charter?

Grüße, Carsten

_______________________________________________
Cose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cose

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Apr 2015 10:19:24 +0100

Hiya,

I was chatting with Kathleen about this and I have a couple
of questions/concerns. Apologies for not being at the JOSE
session in Dallas to ask 'em at the mic, but I had a conflict.
Anyway, Kathleen suggested I ask 'em now rather than when we
get the charter for balloting so here goes....

1) Why is this different from BEEP? BEEP had a lot of backing
from some core/key IETFers, and consumed a lot of effort for
them but also for others who (for a short while) got dragged
into using that day's fashion item. Turned out all that effort
was wasted as BEEP went nowhere. I'm a bit concerned that
we're replicating that pattern here. A good answer might be
to show that folks who aren't "insiders" are really using
CBOR for something that cannot use JOSE and is unrelated to
any IETF WG, and that they are doing that without input from
"insiders." A not so good answer would be of the form "I (an
insider) am using CBOR for <foo> and want COSE."

2) Can you explicitly say why JOSE just does not work for
some key use-cases? (And I do not mean "is not optimal" I
mean "cannot work.") I'm worried that we've done JOSE because
of <A: litany of flaws in CMS/XML>, and now we're doing COSE
because of <B: a litany of flaws in JOSE> and yet a lot the
same people who described A and developed JOSE seem to be
involved here, and so presumably agree with B. For those
folks, what have you learned to change your opinions? Why
not fix JOSE if fixes are needed? Why won't we see the same
pattern repeated here and once COSE is done be asked to
charter DOSE, then EOSE then GOSE etc.?

3) I think PHB has proposed a directly competing approach
to CBOR/COSE. [1] Why is what's proposed here technically
better than that? (Note: I'm not asking if CBOR is or is
not more popular than PHB's ideas.) Are there any other
such directly competing ideas and again, why is this one
the one to standardise?

I'm not sure if answers to the above ought affect charter
text, but they (or discussion ensuing) will affect how I at
least ballot on a charter. I've no idea if other ADs feel
similarly or not. (If it helped, I could ask.)

And lastly for context, I'm not "against" this work, but I
am uneasy about it - I think maybe it's being done too soon
and we'd perhaps be better off seeing if CBOR gets real
traction for uses that really cannot use JOSE. In general I
do think it is a good thing to have security primitives
defined for transports or formats that see widespread usage,
but I'm worried we may be wasting effort here.

Cheers,
S.

[1] https://www.ietf.org/mail-archive/web/jose/current/msg05034.html

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 02 Apr 2015 15:32:55 +0200

Hi Stephen,

thank you for exerting some pushback.  Good design is not possible
without pushback, and it is certainly useful to think again about the
assumptions we are making here.

> 1) Why is this different from BEEP?

The BEEP question is rather difficult to generate an answer for here:
The overlap on constituents between the BEEP community of yore and
today's IoT community is minimal.

Having watched BEEP from a corner of the eye at the time, first of all
I can tell you that BEEP was *weird*.  It provided an abstraction that
didn't really fit anything I was interested in.  Much more general
work is going on on transport abstractions now; I hope they don't run
into the same problem.

More importantly, BEEP also was solving a problem we no longer had:
It became available slightly after the market had decided that
application protocols would be put on top of HTTP; there simply no
longer was any development of new application protocols per se that
could have benefitted from BEEP.

This is clearly different for COSE.  Maybe we'll get a reasonably good
answer for the "who needs this" part of this question after having
collected some more use cases.

So: Could everyone please contribute their reason for being here to
https://github.com/cose-spec/use-cases/blob/master/use-cases.md
?

> some key use-cases?

I had some slides about this:
http://www.ietf.org/proceedings/90/slides/slides-90-jose-2.pdf
(the last three slides are the COSE-specific ones).

More generally, the 10 years of IoT standardization we have had in the
past were mostly about unshackling ourselves from prohibitive
backwards compatibility considerations.  6LoWPAN unshackled itself
from ND classic, ROLL from existing routing protocols, CoRE from HTTP,
...
If we stay serious about IoT, this pattern is unlikely going to end.

> Why won't we see the same

We might, if there is an area of application that is as fundamentally
different from the Web as IoT is, and that is not covered by COSE.
(I'm not aware of such an area, but that is just proof by lack of
imagination.)

> such directly competing ideas and again, why is this one

The design space is indeed humungous.  Why have we arrived here?
Binary-enhanced JSONs are a non-starter, they just carry all the
existing complexity of JSON and add a couple of backwards
compatibility issues.  That's why we did CBOR.

Now the more interesting question is: Why don't we stick with the
original draft-bormann-jose-cose, which is essentially "we don't need
to standardize anything, because JOSE already did our job".  See my
comment about unshackling above.  We do have the opportunity of
simplifying things by not being bound to the same installed-based
issues that JOSE was.  But, make no mistake, JOSE has done 98 % of the
legwork here, and there is no point in reinventing that.

> similarly or not. (If it helped, I could ask.)

We could add more background to the charter.  Having recently done a
charter update proposal on the CoRE WG, I'm not so sure that capturing
the thinking of a specific point in time in the form of charter text
is such a good idea.  But COSE will be short-lived, so maybe we will
have less of an evolution problem.  (If we can write this in a way
that can be re-used for the document, we don't even waste time.)

Thanks again for feeling uneasy; as I said, that certainly helps us
all in thinking more clearly.

Grüße, Carsten

---

From: Derek Atkins <[email-masked]>
Date: Thu, 02 Apr 2015 10:08:14 -0400

Hi,

> insider) am using CBOR for <foo> and want COSE."

I cannot use JOSE because of it's size.  I want COSE+CBOR for tiny
embedded devices where literally bytes matter, and the 33% increase of
base64 is completely wasted.  In my use case I'm going to be nesting
objects, so a signature on a signed object which is itself signing a
signed object, etc.

If there were a 100% pure binary encoding of JSON/JOSE that had the same
compact encoding then I'd be happy to use it, but my understanding is
that there is not, so CBOR/COSE is attractive.

> charter DOSE, then EOSE then GOSE etc.?

Size.  To me there's very little wrong with the JOSE/JSON structure,
except the encoding.

> such directly competing ideas and again, why is this one

I have not looked closely at PHB's suggestion, but JSON-C could also
solve my problem, provided it can be nested.  PHB claims 25 bytes (out
of 129) are for framing with a total of 6 structure elements at 4 bytes
per element.  I haven't looked at the framing or per-element overhead of
CBOR vs JSON-C; if it's a 1:4 ratio then I'd still prefer to see a CBOR
encoding because those extra bytes can add up when nesting 10 objects
deep (an extra 120 bytes).

> [1] https://www.ietf.org/mail-archive/web/jose/current/msg05034.html

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Apr 2015 15:19:26 +0100

Hi Carsten,

> assumptions we are making here.

Thanks for taking this positively! That's great to see.

> today's IoT community is minimal.

Sorry, my question wasn't phrased so well. I did not mean to assert
that BEEP, the protocol, could solve an IETF/IoT problems.

I meant to express my unease at the similar human pattern here of
a set of IETF "insiders" identifying and pushing strongly for a
technology when it's not clear (to me, yet) that there is real
non-insider demand for the work.

(To be clear: I do not think there's any negative connotation at all
to being an insider here, it's a fine thing. But I'd like to know that
the folks who've already inhaled all the fumes aren't, in reality,
the only ones who care about CBOR/COSE.)

> I can tell you that BEEP was *weird*.  

Yes. And starting COSE when JOSE is not yet finished and when
most of the relevant bits of the world are using JSON without yet
having gotten to try play with JOSE is also weird.

> It provided an abstraction that

Sure, but that doesn't touch on the question I asked (badly).

> https://github.com/cose-spec/use-cases/blob/master/use-cases.md

Well, again I'm not seeing the answer there to the question I badly
posed.

The best answer would be if you or someone pointed me at a bunch of
work that's being done using CBOR and that is not being done by
"insiders" and that has security requirements one cannot meet via
DTLS or JOSE.

So I also just took a quick look myself. One way I measure the
relevance of an RFC is via citations. RFC7049 is not referenced by
any other RFC [1] and google scholar only shows me 6 citations to
RFC7049. [2] To me that provides no evidence that we're ready to
start in on COSE and that that'll be worth the investment.

The corresponding numbers I see for RFC4627 are 18 RFCs, [3] and
833 citations, [4] which is quite a bit different. CBOR is of
course much newer so time may well eradicate that difference, but
again that's more indicative of COSE being too early than arguing
that this is the time for doing COSE.

   [1] http://www.arkko.com/tools/allstats/citations-rfc7049.html
   [2]
http://scholar.google.com/scholar?cites=11243383381382361928&as_sdt=2005&sciodt=0,5&hl=en
   [3] http://www.arkko.com/tools/allstats/citations-rfc4627.html
   [4]
http://scholar.google.com/scholar?cites=1045615204790743605&as_sdt=2005&sciodt=0,5&hl=en

> (the last three slides are the COSE-specific ones).

The last 3 slides there simply seem to say "don't use b64." If
there are places where JOSE emits ciphertext, the plaintext of
which is b64 that might be a reason. However, I have no doubt
that, if that is needed, then some simple binary variation for
such cases could be done as a JOSE extension while retaining
compatibility for most forms of ciphertext/signature.

I do not currently accept that the b64 issue alone is sufficient
justification, at this early point in the evolution of CBOR, for
forming a COSE wg.

> If we stay serious about IoT, this pattern is unlikely going to end.

Hmm. That also doesn't touch on any reason why JOSE cannot work.
You may or may not be correct (and you certainly know more than I
about IoT's evolution) and yes, JOSE -> COSE is consistent with
the likes of HTTP -> CoAP. Perhaps it is just not clear to me that
a stack with CoAP, RPL, 6lo etc is what's going to dominate in
the way that HTTP, BGP, IP etc do.

I also recall the WAP forum and it's alternative stack and how by
the time it was ready, the real phone people really used could run
normal TLS/TCP/IP just fine. (But I know already you and I disagree
about the applicability of that lesson-learned for IoT.)

> (I'm not aware of such an area, but that is just proof by lack of

One could argue that that might not be a lack of imagination but
a lack of real demand. But this is a minor point and we can't
know what'll happen in future regardless of whether we do or do
not start a COSE wg.

> compatibility issues.  That's why we did CBOR.

I would have preferred a specific answer there that referred
to (ideally via a list archive URL) PHB's stuff and showed why
what's proposed here is (going to be) better, or which pointed
out the fatal flaw in PHB's work.

> legwork here, and there is no point in reinventing that.

Simplifying 2% of JOSE by replicating 100% of it does not sound
attractive tbh.

> that can be re-used for the document, we don't even waste time.)

I'd suggest we try bottom out the discussion some more before diving
straight into charter discussion. It may be that chunks of the
discussion are better are messages to this list and not as charter
text. So first arguing the case and then deciding what of that to
put in the charter is probably better as a plan I think.

> all in thinking more clearly.

You're welcome. As I said I do not want to be obstructive here but
my unease/concern is intact as of now.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Apr 2015 15:24:39 +0100

Thanks Derek. Would it be fair to say that your message implies
that an awful lot of the technical justification here hinges on
that b64 issue and that we probably ought to have very specific
answers as to why COSE is going to be better than alternatives
before we start a wg?

There are separate and also (though maybe not equally) valid
community arguments that might also come into play but I think
the first order thing is the technical justification which seems
to really hinge on that b64 issue.

S.

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 2 Apr 2015 10:50:53 -0400

Hi,

> to really hinge on that b64 issue.

It's more than just the b64 part, but that's a MAJOR part of it.
My understanding (which is limited and probably flawed) is that CBOR also
gives you the potential to use single-byte element tags.  Maybe the JSON-C
does, too, but I haven't looked at it yet.  String tags for standard
element entries is a non-starter, and using 4 bytes vs. 1 is, IMHO, also a
non-starter.  In my use case I might have 10 (or more) nested objects, so
if each object has 15 extra bytes do to element tag overhead, that's an
extra 150 bytes.  In my environment that's significant and worth the
engineering to re-do it.

I'd encourage a minimalist approach.

I'm of the opinion that the JOSE data structures can (and should) be used
as much as possible.  I would prefer NOT to see re-architecting them and
instead just say "this is how you encode the data model".  It would entail
a registry to provide the single-byte tag numbers for the known data
fields and change any b64 to a binary type.

I'd love for someone more knowledgeable than I give a quick "CBOR vs
JSON-C" comparison.

-derek

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 02 Apr 2015 19:04:29 +0200

> non-insider demand for the work.

... and I was trying to explain why the comparison is not so good,
because BEEP failed for reasons that are quite different from the things
we are discussing here.

COSE is actually the first draft I have written in 20+ years of IETF
work where people are sending me unsolicited specifications with an
attached letter "this is how we are planning to use COSE, do you see any
problems with that".  Yes, outsiders.

> "insiders" and that has security requirements one cannot meet via

Impossible -- because COSE is a copy of JOSE, it fulfills the same
*security requirements*.
It just doesn't work in certain environments.

> start in on COSE and that that'll be worth the investment.

This is more of a demonstration of
-- how long it takes to finish a spec in the IETF -- the ones based on
CBOR just aren't RFCs yet,
-- what kind of no-brainer CBOR is -- it's not something you do research
*on*.  (Some of the research *based* on it is just not published yet;
research also sometimes takes time.)

> The last 3 slides there simply seem to say "don't use b64." 

They do say a bit more, but, yes, base64 is the biggest problem.
The other two are the escape processing required by JSON, and the
handling of strings -- the decimal numerics that get in the way of JSON
usage are not an issue here.

> Perhaps it is just not clear to me that

Well, is HOBA going to dominate in that way?  That's an RFC.

> normal TLS/TCP/IP just fine. 

Well, I still have the scars from the SDPng discussion where people
weren't accepting the idea of fixing SDP because "phones will never
speak XML".  Yeah, right.  If you look at my plenary slides from a while
ago, I'm actually citing WAP as something we should learn from.
WAP did not fail because it took away complexity, it failed because it
simply replaced one form of complexity by a different, "more optimal"
complexity.

> (But I know already you and I disagree

Here, we'll have to agree to disagree.

> out the fatal flaw in PHB's work.

I'm sorry, but that is water under the bridge.  Replacing CBOR by
something that nobody has looked at in detail is not reducing any of the
other work required (and, for one, am not going to waste any time on
something that is not solving my problems).  If minimal work is what you
are interested in, you should argue for draft-bormann-jose-cose as
opposed to draft-schaad-jose, not for redoing the work we did for CBOR
based on something much less useful.

> Simplifying 2% of JOSE by replicating 100% of it does not sound

I don't know what's being replicated here.  We need to:
-- switch to a data encoding that actually use the efficiencies offered
by CBOR, without changing things structurally,
-- assign numbers in some places where right now we only have strings.

None of this is replicating any work already done by JOSE (except that
they already did encode their data in JSON, sometimes awkwardly, but
that is the trivial part).

Grüße, Carsten

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Apr 2015 10:13:46 -0700

> 1) Why is this different from BEEP?

BEEP was designed for an ASCII-based transport, required a fairly complex processor for both encoding and decoding, and also did not do much to try to reduce message size. Those were explicit design choices that have not borne fruit.

> mean "cannot work.")

With those restrictions, probably any existing format (JOSE, XMLENC, CMS, OpenPGP, ...) can be made to work. That is, if you ignore the requirements for reducing the overhead of the encoder/decoder, and ignore the requirements for small messages, we didn't have to ever come up with things beyond whatever-was-first.

> to CBOR/COSE.

It is not "directly competing" in that it inherently takes more resources for encoding and decoding than even JSON does, whereas CBOR takes less than even JSON. Further, it would be a fork of JOSE, and it would require the IETF to be willing to extend or revise JSON. Phill brought up his proposal a few times, and there was no interest, whereas there was a fair amount of interest in CBOR.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 03 Apr 2015 12:06:14 +0100

Hiya,

> problems with that".  Yes, outsiders.

Seeing some of that expressed on this list (or some other list,
or web pages, I don't care about that) would be a fantastic answer
to my question.

> It just doesn't work in certain environments.

Fair enough. But you could point at work being done using CBOR.
It's those pointers I'm after mostly.

> research also sometimes takes time.)

Right, I think I said that too. The point is that we don't have
positive evidence of folks using CBOR from that direction, and
hence me asking for pointers to work being done.

> They do say a bit more, but, yes, base64 is the biggest problem.

So how do we justify going from "let's document a way to use JOSE
but without the b64 penalty" to "let's re-design all of JOSE to
be a thing called COSE that doesn't have the b64 penalty"? I don't
think I've seen that justification tbh.

> Well, is HOBA going to dominate in that way?  That's an RFC.

I've no idea what point you're making there. But in any case, no,
HOBA will not dominate anything. (And I don't believe I've ever
claimed it would.) I think you've also quoted my text above out
of context - it was responding to your point about "unshackling"
with which I don't think I agree. But this is a side-line anyway,
COSE, if justifiable, shouldn't depend on your or my views on
"unshackling" so we're probably better off leaving this be.

> simply replaced one form of complexity by a different, "more optimal"

Partly, yes. But also because time went by, and what appeared to be
hard requirements of a class of constrained equipment turned out to
no longer be required. It's the applicability of that latter point
to challenged networks and devices on which you and I disagree I
think. And it's just fine that we disagree, and the justification
for COSE shouldn't depend on either your or my opinions there
either.

> Here, we'll have to agree to disagree.

Yep.

> I'm sorry, but that is water under the bridge.

That seems non-responsive, so maybe I wasn't clear. If the flaws
in PHB's stuff, or the advantages of COSE compared to PHB's stuff,
were water under the bridge then you should be able to send me the
list archive URL where that was documented. If not, then the water
hasn't yet flowed under an IETF visible bridge;-)

>  Replacing CBOR by
> something that is not solving my problems).  

You are assuming that I accept that CBOR is being, or will be,
widely used. That may be the case, but I have not seen the evidence
for that. If CBOR is being widely used that shouldn't be hard to
demonstrate. And (to repeat myself) it's those pointers to work
based on CBOR that I'd most like to see.

> If minimal work is what you

I am not arguing for PHB's stuff. I'm asking to see the analysis
of why it is the wrong approach and why COSE is the right approach.

> that is the trivial part).

Except that I remember being told similar things about how JOSE
would be almost immediately finished - I just looked back, the
first charter proposal text I found, which is about where we are
on this one, claimed JOSE would be finished in in April 2012 [1] ;-)
I actually don't have a problem with folks making or believing
such claims about how easy it'll all be, but I also don't take
them very seriously. I think re-doing all of JOSE as COSE will be
a big chunk of work that'll consume a lot of people's time.

S.

[1] https://www.ietf.org/mail-archive/web/jose/current/msg00175.html

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 03 Apr 2015 12:10:01 +0100

Hiya,

On 02/04/15 18:13, Paul Hoffman wrote:
> BEEP was designed for an ASCII-based transport, required a fairly
> complex processor for both encoding and decoding, and also did not do
> much to try to reduce message size. Those were explicit design
> choices that have not borne fruit.

Sorry, see my discussion with Carsten. I'm not asking about the
BEEP protocol but about the insider group-think aspects that
ended up with the IETF spending a lot of effort on BEEP.

> 
>> 2) Can you explicitly say why JOSE just does not work for some key
>> use-cases? (And I do not mean "is not optimal" I mean "cannot
>> work.")
> 
> With those restrictions, probably any existing format (JOSE, XMLENC,
> CMS, OpenPGP, ...) can be made to work. That is, if you ignore the
> requirements for reducing the overhead of the encoder/decoder, 

So are we saying that the code footprint of a COSE library will
be a lot smaller than for JOSE? If so, that'd be interesting but
I've not seen that argued. (It was for CBOR vs. JSON, but I don't
think for COSE vs JOSE that I've seen.) Naively, I'd have thought
the code footprint would be dominated by the crypto functions in
both cases. (Note: a fair comparison here would be against a JOSE
library where someone has tried to consider code footprint size,
but I've no idea if anyone has done that.)

I could imagine that one might want to prefer an overall suite
of crypto mechanisms that re-use functions to save footprint. I'm
not clear if COSE plans to do work on that or not, but if any of
it involves novel crypto (which can end up being needed) then
that'd be good to know ahead of time.

> and
> ignore the requirements for small messages, we didn't have to ever
> come up with things beyond whatever-was-first.

So what are the "small message" requirements really? Not wasting
bytes via (esp layers of) b64 or other webby-encoding is clear.

Derek I think implied a requirement that the same small plaintext
be encrypted multiple times without getting bigger but I'm not
clear on if that's needed generally or is a weird corner-case.
(I'm also not clear how the key management for that wouldn't
have to call for bigger and bigger messages or more and more calls
to a KDC-like thing.)

Are there others?

(Also note: I am not asking for work to be done on a requirements
draft. If this is all as obvious as being claimed it should be
possible to deal with the COSE-specific requirements in some
emails, and maybe those might affect some charter text, or not.)

> 
>> 3) I think PHB has proposed a directly competing approach to
>> CBOR/COSE.
> 
> It is not "directly competing" in that it inherently takes more
> resources for encoding and decoding than even JSON does, whereas CBOR
> takes less than even JSON. 

Sorry not to have read all of that but why is that "inherently" true?

> Further, it would be a fork of JOSE, 

Well, COSE would be a fork of JOSE too I guess.

> and
> it would require the IETF to be willing to extend or revise JSON.

Fair enough - if PHB's stuff extends JSON so that current JSON
parsers would barf, then that is a showstopper.

> Phill brought up his proposal a few times, and there was no interest,
> whereas there was a fair amount of interest in CBOR.

Right, but that only tells us to not pursue Phill's thing. It
does not argue that we ought do COSE.

S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 3 Apr 2015 08:46:54 -0400

Hi,

I'll see where I can help from previous discussions.

Sent from my iPhone

> On Apr 3, 2015, at 7:10 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

Yes, we'd like to avoid this as well.
> be a lot smaller than for JOSE?

My understanding is that the data exchanged is much smaller, not sure about the coding footprint or algorithms.
> If so, that'd be interesting but

Size has been discussed on list (I believe - JOSE) and in meetings and has been the main driver.
> emails, and maybe those might affect some charter text, or not.)
Agreed.
> Sorry not to have read all of that but why is that "inherently" true?

I did get a reasonable answer for this and hopefully someone will chime in.  I'll reach back out to the person and respond once I hear back - IETF week was a long one.
> does not argue that we ought do COSE.

It's finally been posted in a draft, I believe and it had not been before.  Looking at both answers in parallel will help to get what's needed sooner and I'm also interested to see reviews of PHBs work on JOSE as part of this process to show due diligence.

Thanks,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 3 Apr 2015 09:58:46 -0400

Hi,

Sent from my iPhone

> problems with that".  Yes, outsiders.

Please encourage them to send their messages to the list.  Is very helpful that we see the possible uses and real customers of potential work.
> based on something much less useful.

This doesn't help enough and there have been a couple of responses that just say use this and not what PHB is proposing and a seeming unwillingness to review his proposal to explain any issues with it.  That doesn't show why one direction should be pursued versus another, it looks more like a bias.  My request is for a few of you to review PHB's proposal to show clear comparisons and help us move forward.

I'd like these to be on technical merits and needs of consumers with a healthy on list discussion.

Thanks,
Kathleen

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 3 Apr 2015 07:46:24 -0700

> Yes, we'd like to avoid this as well.

The proposed charter is not "a lot of effort", certainly not as much as BEEP took. BEEP was a format, a transport protocol, and many other things: COSE is a format.

It is also not appropriate to say that either BEEP was consumed by "insider group-think aspects that ended up with the IETF spending a lot of effort". In fact, the opposite was true: BEEP was designed by people not familiar with the requirements of the IoT community, but who had a long history of doing IETF formats and protocols. Those people thought we could impose our new protocol on others. The COSE work, however, is being motivated by people within the IoT community.

> My understanding is that the data exchanged is much smaller, not sure about the coding footprint or algorithms.

Sorry, I had forgotten that you might not have followed the discussion that lead to the CBOR spec in the Apps Area. CBOR's main reason for existence is smaller coding size, not smaller data. If you only care about smaller data, "gzip of JSON" or some of the recent unstandardized formats are probably fine. On the other hand, if you want a format whose code for encoding and decoding is smaller than JSON, and that takes less power to run than JSON for typical data, that's where CBOR shines.

> Size has been discussed on list (I believe - JOSE) and in meetings and has been the main driver.

Data size is a driver for some, and CBOR works well for that, but nowhere is it the primary driver for COSE. In order to get good size with JSON, or with some of the other unstandardized formats, you need much more code overhead, and you get more failure cases when an encoder doesn't follow a size-limiting profile of the format. With CBOR, those mostly fall out by themselves and, where they don't, checking take less code overhead.

> I did get a reasonable answer for this and hopefully someone will chime in.  I'll reach back out to the person and respond once I hear back - IETF week was a long one.

It is inherently true for many reasons.
- CBOR has no Unicode escaping rules that must be applied to object names
- CBOR has no whitespace removal rules
- CBOR has no "real numbers as text" to float rules
and so on.

>> Well, COSE would be a fork of JOSE too I guess.

It could be, but it's not, at least in the document many of us are considering. COSE is being informed by he JSON work, but is not at all a fork. For example, COSE will likely not follow the JOSE mistake of calling HMACs "signatures".

>> parsers would barf, then that is a showstopper.

It does exactly that. It uses currently-illegal signaling as a way of introducing the new elements. That's a reasonable design and, in fact, the only design that I could think of that is guaranteed to work.

> It's finally been posted in a draft, I believe and it had not been before.

Maybe we are talking about different things: Phill posted draft-hallambaker-jsonbcd in 2013 and tried to get interest in it, but failed.

>  Looking at both answers in parallel will help to get what's needed sooner and I'm also interested to see reviews of PHBs work on JOSE as part of this process to show due diligence.

Wearing my ex-chair hat of the JSON WG: please don't. Suggesting that the IETF should extend or revise JSON would be politically tricky and almost none of the people active in the JSON WG wanted to do so.

--Paul Hoffman

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 3 Apr 2015 11:04:11 -0400

On Fri, Apr 3, 2015 at 10:46 AM, Paul Hoffman <[email-masked]> wrote:

> The proposed charter is not "a lot of effort", certainly not as much as
> BEEP took. BEEP was a format, a transport protocol, and many other things:
> COSE is a format.
>
> It is also not appropriate to say that either BEEP was consumed by
> "insider group-think aspects that ended up with the IETF spending a lot of
> effort". In fact, the opposite was true: BEEP was designed by people not
> familiar with the requirements of the IoT community, but who had a long
> history of doing IETF formats and protocols. Those people thought we could
> impose our new protocol on others. The COSE work, however, is being
> motivated by people within the IoT community.
>
> > My understanding is that the data exchanged is much smaller, not sure
> about the coding footprint or algorithms.
>
> Sorry, I had forgotten that you might not have followed the discussion
> that lead to the CBOR spec in the Apps Area. CBOR's main reason for
> existence is smaller coding size, not smaller data. If you only care about
> smaller data, "gzip of JSON" or some of the recent unstandardized formats
> are probably fine. On the other hand, if you want a format whose code for
> encoding and decoding is smaller than JSON, and that takes less power to
> run than JSON for typical data, that's where CBOR shines.
>
> Data size is a driver for some, and CBOR works well for that, but nowhere
> is it the primary driver for COSE. In order to get good size with JSON, or
> with some of the other unstandardized formats, you need much more code
> overhead, and you get more failure cases when an encoder doesn't follow a
> size-limiting profile of the format. With CBOR, those mostly fall out by
> themselves and, where they don't, checking take less code overhead.
>
> > I did get a reasonable answer for this and hopefully someone will chime
> in.  I'll reach back out to the person and respond once I hear back - IETF
> week was a long one.
>
> It could be, but it's not, at least in the document many of us are
> considering. COSE is being informed by he JSON work, but is not at all a
> fork. For example, COSE will likely not follow the JOSE mistake of calling
> HMACs "signatures".
>
> >>> and
> It does exactly that. It uses currently-illegal signaling as a way of
> introducing the new elements. That's a reasonable design and, in fact, the
> only design that I could think of that is guaranteed to work.
>
> Maybe we are talking about different things: Phill posted
> draft-hallambaker-jsonbcd in 2013 and tried to get interest in it, but
> failed.
>
> >  Looking at both answers in parallel will help to get what's needed
> sooner and I'm also interested to see reviews of PHBs work on JOSE as part
> of this process to show due diligence.
>
> Wearing my ex-chair hat of the JSON WG: please don't. Suggesting that the
> IETF should extend or revise JSON would be politically tricky and almost
> none of the people active in the JSON WG wanted to do so.
>

Please send pointers to the previous reviews or I'd like to see some posted
on JOSE.  I thought PHB said he posted something last week, maybe I'm wrong
and it's old, but I don't see why you oppose reviews of competing proposals
to show this was done fairly.

-- 

Best regards,
Kathleen

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 3 Apr 2015 09:06:00 -0700

On Apr 3, 2015, at 8:04 AM, Kathleen Moriarty <[email-masked]> wrote:
> Please send pointers to the previous reviews or I'd like to see some posted on JOSE.  I thought PHB said he posted something last week, maybe I'm wrong and it's old, but I don't see why you oppose reviews of competing proposals to show this was done fairly.

Offline, Kathleen just pointed out her and Stephen's questions were about draft-hallambaker-joseunencoded and Phill's assertion at the plenary that it alleviates the need for COSE. I thought we were discussing draft-hallambaker-jsonbcd, and my earlier comments were about that document.

draft-hallambaker-joseunencoded appears to only affect COSE if you believe that the only reason for IoT objects not using JOSE is that we need smaller messages, and only smaller due to they base64-encoded cryptographic material. That's only a small part of COSE, although it is the easiest one to see if you are still thinking in terms of JOSE.

draft-hallambaker-joseunencoded does show that it might be useful to use non-base64'd data for detached signatures, and COSE already has that as a use case. However, COSE won't be limited to binary data that can be encoded as UTF8.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 03 Apr 2015 19:23:43 +0100

On 03/04/15 17:06, Paul Hoffman wrote:
> On Apr 3, 2015, at 8:04 AM, Kathleen Moriarty
> <[email-masked]> wrote:
>> Please send pointers to the previous reviews or I'd like to see
>> some posted on JOSE.  I thought PHB said he posted something last
>> week, maybe I'm wrong and it's old, but I don't see why you oppose
>> reviews of competing proposals to show this was done fairly.
>
> Offline, Kathleen just pointed out her and Stephen's questions were
> about draft-hallambaker-joseunencoded and Phill's assertion at the
> plenary that it alleviates the need for COSE. I thought we were
> discussing draft-hallambaker-jsonbcd, and my earlier comments were
> about that document.

To be clear, my questions are not motivated by that. I do agree
with Kathleen though that it'd be wise to have answers to hand.

S.

> 
> draft-hallambaker-joseunencoded appears to only affect COSE if you
> believe that the only reason for IoT objects not using JOSE is that
> we need smaller messages, and only smaller due to they base64-encoded
> cryptographic material. That's only a small part of COSE, although it
> is the easiest one to see if you are still thinking in terms of
> JOSE.
> 
> draft-hallambaker-joseunencoded does show that it might be useful to
> use non-base64'd data for detached signatures, and COSE already has
> that as a use case. However, COSE won't be limited to binary data
> that can be encoded as UTF8.
> 
> --Paul Hoffman _______________________________________________ Cose
> mailing list [email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 03 Apr 2015 20:34:45 +0200

Hi Derek,

I would like to better understand this statement:

On 04/02/2015 04:50 PM, Derek Atkins wrote:
> I cannot use JOSE because of it's size.

I know that you are playing in an extremely constrained space (with
RFIDs) and so I am wondering what specific scenario you have in mind.

Just saying that you cannot use it does not give me enough context to
understand your limitations.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 03 Apr 2015 20:34:36 +0200

Hi Goeran,

I don't think that these use cases are useful since they are pretty much
independent of the JOSE/CBOR/COSE question.

The interesting question is whether there are cases where you cannot get
your use case to work without having COSE. Do you have such a use case?

Ciao
Hannes

On 04/02/2015 08:05 AM, Göran Selander wrote:
> is that the cryptographic formats provided by JOSE may not be
> sufficiently flexible to allow certain optimizations desirable for
> constrained devices, e.g.  
> 
>   * Detached AAD
> "a standards-track specification covering the same cryptographic formats
> from JOSE and optimizations for constrained device processing, expressed
> in CBOR"
> 
> 
> Best regards,
> Göran
> 
> 
> To: Carsten Bormann <[email-masked] <mailto:[email-masked]>>, Paul Hoffman
> <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
>         发件人：Carsten Bormann<[email-masked] <mailto:[email-masked]>>
>         日　期：2015年04月02日 05:43:31
>         抄　送：[email-masked] <mailto:送：[email-masked]><[email-masked]
>         <mailto:[email-masked]>>
>         forth,
>         information
>         [email-masked] <mailto:[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 03 Apr 2015 20:38:33 +0200

Hi Stephen,

you raise good questions. Comments below.

> insider) am using CBOR for <foo> and want COSE."

You raise interesting points. We are obviously on an optimization track
here and there is the perceived need to re-invent everything (not only
with CBOR but with almost everything). Of course, you could call it
innovation but you can also argue whether this is indeed necessary (and
BEEP provides an interesting lesson here since there is more than just
the number of bits on the wire that are important for a technology
getting adopted). Note that this is not limited to IoT technologies but
more broadly in the IETF in general: just look at HTTP 2 or TLS 1.3.

In the early days of the IoT work in the IETF we said that we could
re-use the IETF protocols but then we started to slowly re-build
everything and I am myself wondering whether we are sometimes going a
bit too far since it is a lot of effort to educate the wider Internet
community about all this new stuff.

I cannot tell you whether we crosses the line of useful optimizations
already or not.

On the other hand we are never asking ourselves these question when big
companies propose something (see all the Web work or the token binding
work). So, why start now? I have often heard the phrase "let the market
decide".

> charter DOSE, then EOSE then GOSE etc.?

In the use cases I see in IoT JOSE would of course work; the messages
would just be a bit larger. There are some pretty limited radio
technologies around and of course it would take longer to transmit data.
Whether that matters or not depends on the application context and is
not easy to answer in a general way.

I am less concerned about the code size in this case (to be honest): the
cryptographic algorithms are actually the heavy parts.

I guarantee you that there will be a DOSE, and many other activities
that will follow afterwards. Every-time I thought we reached the end I
was already wrong and there was yet another more fashionable version around.

> such directly competing ideas and again, why is this one

I will definitely look at the solution PHB proposed.

> but I'm worried we may be wasting effort here.

I felt a bit uneasy myself, not necessarily about COSE, but rather how
CBOR was introduced to the IETF and how the show was run so far with COSE.

I am a bit unclear what motivates various proponents to participate in
this work. It can hardly be IoT.

Ciao
Hannes

---

From: "Derek Atkins" <[email-masked]>
Date: Fri, 3 Apr 2015 15:35:00 -0400

Hi Hannes,

> RFIDs) and so I am wondering what specific scenario you have in mind.

It's a bit hard to go into too much detail, but I need to be able to store
multiply-signed (nested) documents on devices that have, maybe, 5KB of
storage space total (and that 5KB needs to include my code, crypto keys,
and other ancillary data as well).  So in my environment every byte
matters.

> understand your limitations.

There are two aspects here.  First, parsing strings takes significantly
more code than parsing binary.  Second, storing strings takes
significantly more space than storing integers.  *COULD* I use JWS+JSON? 
Arguably, yes, but as-written after nesting 10 signatures I've now
expanded the document by 33% 10 times.  That blows up very fast.

Now, going back to PHB's "encode as binary" is a step in the right
direction, so I don't get that 33% bloat, but I still have to deal with
string parsing vs binary parsing.

I'm really not sure, short of having you sign an NDA to explain my full
situation, how to give you more information.

I'll note that I'm still in the design phase of my project; I don't
actually have code today, which is yet another reason I'm trying to find
the best fit.  I don't have any history I have to maintain or
compatibility issues.

Hope this helps,

-derek

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 04 Apr 2015 03:18:23 +0100

Hiya,

Not answering on all points, just where I think I can add to
the discussion...

> I cannot tell you whether we crosses the line of useful optimizations

Yep. I feel similarly. But I also very much respect folks who do not
feel that unease.

> work). So, why start now? I have often heard the phrase "let the market

The web is different right now. There are a very few browser
implementers with significant marker share, a chunk of whom need
to be on board for most web innovations, if those are to get traction.
And if one does not get that kind of browser buy-in, then there is
not much commercial value to an RFC, (of that kind) except if
it's written based on other motives. So yes, that does currently give
the browser implementers some power here. Mind you we both remember the
previous generations of N-hundred pound gorillas, many of whom are not
so gorilla-like any more, so I expect the same will happen in the
browser case, in (not too much) time. (If they're wise, they will
realise their power is temporally limited, but I've no idea why this
crop of developers ought be wiser than previous ones;-)

The above is a reason why chartering tokbind is currently "important"
but HOBA (as a non-random example:-) is not. But that actually is ok -
a big part of what we're about here relates to impact. In general, we
do, and should, prefer to not work on stuff that won't matter. And
that's partly why questioning COSE is fair game IMO.

> not easy to answer in a general way.

I like the way the above is stated. JOSE can in fact work, but
there is for sure a (possibly niche? possibly mainstream?) set
of use-cases where JOSE does not work.

The question here is how to address that - via a tweak to JOSE or
starting over, the latter being how I read the COSE proposal.

> cryptographic algorithms are actually the heavy parts.

Code size is a concern for me here, not not because I care about code
size:-) If the best way to reduce code size is via fewer basic crypto
functions, then that can and has lead to "interesting" crypto choices.
(CCM vs GCM for example, and perhaps the idea oF AES based MACs.) That
kind of choice can impact a lot on interoperability and security and
privacy.

So from an inventing-cryto-stuff-is-bad perspective, that code size
is an issue for this group is a source of inevitable potential concern.

> 
> I guarantee you that there will be a DOSE, 

Sigh. But yeah, probably.

> and many other activities

Great, thanks. And I think others are doing similarly. In fact I
think this part is now in-hand. (But please do review stuff.)

> this work. It can hardly be IoT.

So ask 'em! (I thought that bit was clear tbh.)

S.

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 4 Apr 2015 11:31:58 -0700

I can easily live with the charter as it currently stands.

There are three things which we might want to include in the charter:

1.  Since constrained environments are one of the primary targets for this
work,
message size and code size are to be considered whenever decisions are made.

2.  We will coordinate with the ACE and CoAP working groups during last
calls of the working group documents.

3.  The working group will not deal with issues around key management and
the binding of identities and keys, the working group is only focused on
secure message formatting.

As I said to start with, I don't feel strongly that any of these issues need
to be in the charter, I am just raising them as issues.

Jim

> -----Original Message-----
> From: Cose [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Wednesday, April 01, 2015 2:18 PM
> To: [email-masked]
> Subject: [Cose] Are we finished with the charter?
> 
> wants something about a JWK mapping, but I don't see any other support for
> it.
> 
> > using JSON representation. This working group will reuse the work done
> > by JOSE, adapting it to the capabilities of CBOR. This will rely on
> > the JOSE registries, which, where this provides additional efficiency,
> > will be expanded with additional information.
> >
> > The Working Group will use a wiki to track desired use cases for its
> > work, but does not intend to publish this as an RFC.
> >
> > ## Milestones
> >

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 04 Apr 2015 20:47:21 +0100

Hi Jim,

Two questions below.

> message size and code size are to be considered whenever decisions are made.

Code-size minimisation can call for novel crypto mechanisms.
Say, (inventing one just for the sake of an example), a node
implements chacha20-poly1305 as an AEAD cipher and also has a
need for a MAC, then is this proposed WG going to take on the
crypto work of defining such a thing? I would hope not. How
is it proposed to handle such cases?

> secure message formatting.

You did not use the term CBOR above.

Do you see this proposed WG only defining crypto based mechanisms
for CBOR, or more generally aiming to be independent of how the
platform handles structured data? I assume (based on the list name
and proponents) that the proposal here is only to consider CBOR
but that might be a bad assumption.

S.

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 4 Apr 2015 14:52:18 -0700

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Saturday, April 04, 2015 12:47 PM
> To: Jim Schaad; 'Paul Hoffman'; [email-masked]
> > 1.  Since constrained environments are one of the primary targets for
> > this work, message size and code size are to be considered whenever
> > decisions are made.
> 
> Say, (inventing one just for the sake of an example), a node implements
> chacha20-poly1305 as an AEAD cipher and also has a need for a MAC, then is
> this proposed WG going to take on the crypto work of defining such a thing? I
> would hope not. How is it proposed to handle such cases?

It has already been stated that we are going to do some of this in the charter.  After all, there is a work item of doing some constrained appropriate algorithms to be done in a draft.  I would not expect that chacha20-poly1305 would so up here.  However it is possible that there may be a call for doing the new EC curve and possible a static-static version of ECDH as part of this work.  Again I don't know that would be the case and I would probably start by arguing that it should be done in a different group as the first step.  Only those things that are well understood and deemed necessary should be done now.

> 
> > 2.  We will coordinate with the ACE and CoAP working groups during
> > last calls of the working group documents.
> >
> > 3.  The working group will not deal with issues around key management
> > and the binding of identities and keys, the working group is only
> > focused on secure message formatting.
> 
> Do you see this proposed WG only defining crypto based mechanisms for
> CBOR, or more generally aiming to be independent of how the platform
> handles structured data? I assume (based on the list name and proponents)
> that the proposal here is only to consider CBOR but that might be a bad
> assumption.

I would be more than happy to put CBOR into that, I kind of assumed it was implicit from the rest of the charter.  I was thinking in terms of not getting into key management or certificates would be good statements to have in the charter for limiting purposes.  At some point the ACE and CoAP groups are going to need to figure out how to do both of these and I wanted it to be clear it was not something this WG was going to deal with.

Jim

> 
> S.
> 
> >
> > As I said to start with, I don't feel strongly that any of these
> > issues need to be in the charter, I am just raising them as issues.
> >
> > Jim
> >
> >
> >>> binary format for the serialization of data structured to an
> >>> extended version of the JSON data model. One motivation for CBOR was
> >>> to make this data model more amenable to constrained nodes and
> >>> constrained node networks (RFC 7228).
> >>>
> >>> for message authentication (MACs), encryption, and digital
> >>> signatures, using JSON representation. This working group will reuse
> >>> the work done by JOSE, adapting it to the capabilities of CBOR. This
> >>> will rely on the JOSE registries, which, where this provides
> >>> additional efficiency, will be expanded with additional information.
> >>>
> >>> or to JOSE formats. This lack of a need for bit-for-bit
> >>> compabitility which will enable some simplification in the adaptation
> process.
> >>>
> >>> - registration for algorithms (such as AES-CCM-8) that are
> >>> appropriate for constrained environments.
> >>>
> >>> * June 2015: Submit COSE specification to the IESG, for publication
> >>> as a Proposed Standard
> >>>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 04 Apr 2015 23:15:12 +0100

Hiya,

On 04/04/15 22:52, Jim Schaad wrote:
> 
> 
>> -----Original Message----- From: Stephen Farrell
>> [mailto:[email-masked]] Sent: Saturday, April 04, 2015
>> 12:47 PM To: Jim Schaad; 'Paul Hoffman'; [email-masked] Subject: Re:
>> [Cose] Are we finished with the charter?
>> 
>> 
>> Hi Jim,
>> 
>> Two questions below.
>> 
>>> 1.  Since constrained environments are one of the primary targets
>>> for this work, message size and code size are to be considered
>>> whenever decisions are made.
>> 
>> Code-size minimisation can call for novel crypto mechanisms. Say,
>> (inventing one just for the sake of an example), a node implements 
>> chacha20-poly1305 as an AEAD cipher and also has a need for a MAC,
>> then is this proposed WG going to take on the crypto work of
>> defining such a thing? I would hope not. How is it proposed to
>> handle such cases?
> 
> It has already been stated that we are going to do some of this in
> the charter.  After all, there is a work item of doing some
> constrained appropriate algorithms to be done in a draft.  I would
> not expect that chacha20-poly1305 would so up here.  However it is
> possible that there may be a call for doing the new EC curve and
> possible a static-static version of ECDH as part of this work.  Again
> I don't know that would be the case and I would probably start by
> arguing that it should be done in a different group as the first
> step.  Only those things that are well understood and deemed
> necessary should be done now.

Cool, I think we agree.

So where I think we'd want to (as usual) draw the line is before
we get into the putative WG doing novel crypto. For example, I'd
say that defining a way to use 25519 or 448 for static-static ECDH
would be fine, but defining a new signature scheme would not.
Things like that latter really would need to get proper crypto
review. (That could be done with or via CFRG or some other way,
as usual.)

That said, I would expect there to be at least some demands for
novel crypto arising here, (for code footprint reasons) so I'd
say it'd be good for a charter to be as explicit as possible
about that.

> 
>> 
>>> 2.  We will coordinate with the ACE and CoAP working groups
>>> during last calls of the working group documents.
>>> 
>>> 3.  The working group will not deal with issues around key
>>> management and the binding of identities and keys, the working
>>> group is only focused on secure message formatting.
>> 
>> and proponents) that the proposal here is only to consider CBOR but
>> that might be a bad assumption.
> 
> I would be more than happy to put CBOR into that, I kind of assumed
> it was implicit from the rest of the charter.  I was thinking in
> terms of not getting into key management or certificates would be
> good statements to have in the charter for limiting purposes.  At
> some point the ACE and CoAP groups are going to need to figure out
> how to do both of these and I wanted it to be clear it was not
> something this WG was going to deal with.

Ok, thanks. So that brings us (well, me:-) back to the still
unanswered question as to whether or not CBOR really has enough
usage to warrant forming a WG dedicated to crypto-for-CBOR. If
it does, the answer is easy. If not, what is best to do is
less clear for me.

S.

>>>> -----Original Message----- From: Cose
>>>> [mailto:[email-masked]] On Behalf Of Paul Hoffman Sent:
>>>> Wednesday, April 01, 2015 2:18 PM To: [email-masked] Subject:
>>>> [Cose] Are we finished with the charter?
>>>> 
>>>> There have been no messages for a few days; maybe we are done.
>>>> Mike wants something about a JWK mapping, but I don't see any
>>>> other support for it.
>>>> 
>>>>> On Mar 29, 2015, at 8:11 AM, Kepeng Li
>>>>> <[email-masked]>
>>>> wrote:
>>>>> 
>>>>> Thanks for the input.
>>>>> 
>>>>> concise binary format for the serialization of data
>>>>> structured to an extended version of the JSON data model. One
>>>>> motivation for CBOR was to make this data model more amenable
>>>>> to constrained nodes and constrained node networks (RFC
>>>>> 7228).
>>>>> 
>>>>> representations for message authentication (MACs),
>>>>> encryption, and digital signatures, using JSON
>>>>> representation. This working group will reuse the work done
>>>>> by JOSE, adapting it to the capabilities of CBOR. This will
>>>>> rely on the JOSE registries, which, where this provides 
>>>>> The resulting formats will not be cryptographically
>>>>> convertible from or to JOSE formats. This lack of a need for
>>>>> bit-for-bit compabitility which will enable some
>>>>> simplification in the adaptation
>> process.
>>>>> 
>>>>> specification covering the same cryptographic formats from
>>>>> JOSE, expressed in CBOR; - registration for algorithms (such
>>>>> as AES-CCM-8) that are appropriate for constrained
>>>>> environments.
>>>>> 
>>>>> The Working Group will use a wiki to track desired use cases
>>>>> for its work, but does not intend to publish this as an RFC.
>>>>> 
>>>>> ## Milestones
>>>>> 
>>>>> * July 2015: Submit COSE constrained-appropriate algorithms
>>>>> to the IESG, for publication as a Proposed Standard
>>>>> 
>>>>> I will put the draft charter to a wiki page, so we can track
>>>>> changes
>>> from that.
>>>> 
>>>> _______________________________________________ Cose mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/cose
>>> 
>>> _______________________________________________ Cose mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/cose
>>> 
>>> 
>

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 4 Apr 2015 15:32:26 -0700

> Sent: Saturday, April 04, 2015 3:15 PM
> >> then is this proposed WG going to take on the crypto work of defining
> >> such a thing? I would hope not. How is it proposed to handle such
> >> cases?
> >
> > It has already been stated that we are going to do some of this in the
> > charter.  After all, there is a work item of doing some constrained
> > appropriate algorithms to be done in a draft.  I would not expect that
> > chacha20-poly1305 would so up here.  However it is possible that there
> > may be a call for doing the new EC curve and possible a static-static
> > version of ECDH as part of this work.  Again I don't know that would
> > be the case and I would probably start by arguing that it should be
> > done in a different group as the first step.  Only those things that
> > are well understood and deemed necessary should be done now.
> 
> Cool, I think we agree.
> 
> So where I think we'd want to (as usual) draw the line is before we get into the
> putative WG doing novel crypto. For example, I'd say that defining a way to
> use 25519 or 448 for static-static ECDH would be fine, but defining a new
> signature scheme would not.
> Things like that latter really would need to get proper crypto review. (That
> could be done with or via CFRG or some other way, as usual.)
> 
> That said, I would expect there to be at least some demands for novel crypto
> arising here, (for code footprint reasons) so I'd say it'd be good for a charter
> to be as explicit as possible about that.

Novel crypto is something that I would run away from as quick as possible.   I really don't want to get into that.  I have a hard enough time understanding some parts of "normal" crypto.

Jim

> >>> management and the binding of identities and keys, the working group
> >>> is only focused on secure message formatting.
> >>
> >> handles structured data? I assume (based on the list name and
> >> proponents) that the proposal here is only to consider CBOR but that
> >> might be a bad assumption.
> >
> > I would be more than happy to put CBOR into that, I kind of assumed it
> > was implicit from the rest of the charter.  I was thinking in terms of
> > not getting into key management or certificates would be good
> > statements to have in the charter for limiting purposes.  At some
> > point the ACE and CoAP groups are going to need to figure out how to
> > do both of these and I wanted it to be clear it was not something this
> > WG was going to deal with.
> 
> Ok, thanks. So that brings us (well, me:-) back to the still unanswered question
> as to whether or not CBOR really has enough usage to warrant forming a WG
> dedicated to crypto-for-CBOR. If it does, the answer is easy. If not, what is best
> to do is less clear for me.
> 
> S.
> 
> 
> >
> > Jim
> >
> >>
> >> S.
> >>
> >>>
> >>>> Mike wants something about a JWK mapping, but I don't see any other
> >>>> support for it.
> >>>>
> >>>>> extended version of the JSON data model. One motivation for CBOR
> >>>>> was to make this data model more amenable to constrained nodes and
> >>>>> representations for message authentication (MACs), encryption, and
> >>>>> digital signatures, using JSON representation. This working group
> >>>>> will reuse the work done by JOSE, adapting it to the capabilities
> >>>>> of CBOR. This will rely on the JOSE registries, which, where this
> >>>>> adaptation
> list

---

From: "Derek Atkins" <[email-masked]>
Date: Sat, 4 Apr 2015 22:08:17 -0400

HI,

>> > are well understood and deemed necessary should be done now.

We already have OMAC for making a MAC out of a block cipher.. It's the
basis of AES-CMAC, and can be applied to pretty much any block cipher.  So
no, I wouldn't expect we would need to do any real work here other that
saying to use the OMAC construction.

As for ECDH, I would suggest that we might also consider AEDH in
static-static or static-ephemeral form in addition.

> Novel crypto is something that I would run away from as quick as possible.
>   I really don't want to get into that.  I have a hard enough time
> understanding some parts of "normal" crypto.

Not sure your definition of "novel".  See above about AEDH as an
alternative to ECDH for efficient key agreement in low-power environments.

>> >>> last calls of the working group documents.

I would also think we might pay attention to DICE as well.

>> to do is less clear for me.

Personally I would still like to see a side-by-side comparison of CBOR to
JSON-C for, e.g., a JWS object.

-derek

---

From: Mike Jones <[email-masked]>
Date: Sun, 5 Apr 2015 19:38:44 +0000

> Novel crypto is something that I would run away from as quick as possible.   I really don't want to get into that.  I have a hard enough time understanding some parts of "normal" crypto.

+1 ;-)

> Jim

				-- Mike

---

From: Derek Atkins <[email-masked]>
Date: Mon, 06 Apr 2015 14:20:36 -0400

[snip]
> think I've seen that justification tbh.

Personally I don't see us taking that leap.  At least *I* don't see
that.  I see it more as "let's document how to use JOSE without the b64
and other JSON penalties, and make the necessary changes to simplify the
data structure encodings, encoder code, and decoder code".  That's not
the same thing as "let's re-design all of JOSE" which, frankly, I don't
see anyone specifically suggesting or supporting.

[snip]
> hasn't yet flowed under an IETF visible bridge;-)

I think that Jim Schaad's email showing a 35-40 byte savings of COSE
over JOSE-B/C is probably sufficient, considering the complexity of a
JSON encoder/decover versus a CBOR encoder/decoder.

> based on CBOR that I'd most like to see.

There's at least a dozen (or more) CBOR implementations out there.  See
http://cbor.io/

I cannot comment on how widely used they are, but I know that I'm
planning to use it.

-derek

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 6 Apr 2015 19:31:55 +0000

>see anyone specifically suggesting or supporting.

Agree.  There are some small changes to get to more idiomatic CBOR that I think most folks already agree with.  There may be other changes that a WG might want to make (e.g. "some simplification" in the current charter text), but the bar that was proposed earlier on the JOSE list was only taking changes that had a compelling code size, wire size, or security improvement associated with them.  We could decide to add text of that nature to the charter to avoid the perception that we're working on a complete redesign.

-- 
Joe Hildebrand

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 6 Apr 2015 16:17:58 -0400

> > hasn't yet flowed under an IETF visible bridge;-)

PHB just posted his 4-page draft Wednesday of IETF week, after the JOSE
meeting.  He brought this up during the JOSE session and during the plenary
at the mic.  He told me after the JOSE session that he would get the draft
posted, so there really hasn't been too much time, but reviews are
flowing.  The reviews on that draft and feasibility for this problem space
are being discussed  mostly on the JOSE list.

http://www.ietf.org/mail-archive/web/jose/current/msg05066.html

My opinion is that we need to allow that conversation to happen and give it
a little more time.

> JSON encoder/decover versus a CBOR encoder/decoder.

This type of discussion and analysis has also been helpful.

> I cannot comment on how widely used they are, but I know that I'm

I'd like to see this conversation develop a bit more and also want to be
careful that we don't waste a ton of time in the lead up for a WG that may
only produce a couple of drafts with plans to do that quickly.  We
shouldn't be a barrier to getting work done.  If there are enough use cases
where this makes sense, having it flow quickly and seeing what comes of it
may be the way to consume less overall time.

ACE needs a solution or they may design something else, that was pretty
clear in Dallas - but the WG would prefer to refer to something else.

I'm going to be pretty tied up this week, so I may be more quiet until
Friday.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Göran Selander <[email-masked]>
Date: Tue, 7 Apr 2015 05:25:40 +0000

Hi Hannes,

Sorry for late reply.

>your use case to work without having COSE. Do you have such a use case?

As has been mentioned by others, it depends on what you assume. If you
assume that message size and code footprint doesn’t matter, then there is
little need for COSE or similar. I guess this is your point of view.

But I think it is fair to acknowledge that there are other points of view
in the CoRE / ACE community. In Honolulu when we presented
http://tools.ietf.org/drafts/draft-selander-ace-object-security-00,  the
main comment we got (including people from ARM) was that our proposed
message format based on wrapping with JOSE creates too much overhead, e.g.
because of fragmentation in 802.15.4.

This was one of the reasons for considering message format optimizations
using COSE-00 etc. in version -01 (Appendix C). We could use our tailor
made message format or make our own profile of JOSE formats, but it seems
more fruitful to define a new format for common needs in those cases when
message size, footprint etc. matters.

Best,  
Göran

>> from JOSE, expressed in CBOR"
>>