Subject: [Cose] Charter Pull Request #2

From: "Jim Schaad" <[email-masked]>
Date: Wed, 8 Apr 2015 16:32:08 -0700

I have created a pull request to deal with the issues that I raised over the
weekend.  As part of the text changes I am suggested are some that are aimed
at what I believe are the issues that both Joe and Stephen have raised about
scope.

Please look over them and comment.

Jim

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Apr 2015 19:43:35 -0400

It's kind of unfair to expect people to know where the draft charter is, or even what a "pull request" is. For those not in the know, the draft charter is at:
   https://github.com/cose-spec/wg-charter/blob/master/draft-charter.md
and Jim's proposed changes are are:
   https://github.com/cose-spec/wg-charter/pull/2

---

From: "Kepeng Li" <[email-masked]>
Date: Thu, 09 Apr 2015 09:30:55 +0800

I copy the proposed texts here:

---------------------------------------------------------------------------
-------------------------

Criteria that should be considered on making decisions in changing from a
JOSE to a CBOR encoding are:
- Keeping the current JOSE paradigms and formatting where feasible.
- Minimizing message size and code size should be considered (for the
constrained environments where we expect to use this).
- Improving security.
- Providing new functionality that uses of JOSE did not require, but are
required for the new use cases.

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

Issues dealing with key management and binding of keys to identities are
out of scope for the working group.

The Working group will coordinate its progress with the ACE, DICE and CoAP
working groups to ensure that we are fulfilling the needs of these
constituencies. Other groups may be added to this list as the set of use
cases is expanded.

――――――――――――――――――――――――――――――――――――――――――――――――――

For the last paragraph, I propose to change CoAP to CoRE.

Thanks,

Kind Regards
Kepeng

在 9/4/15 7:43 am， "Paul Hoffman" <[email-masked]> 写入:

>It's kind of unfair to expect people to know where the draft charter is,
>or even what a "pull request" is. For those not in the know, the draft
>charter is at:
>_______________________________________________
>Cose mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cose

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Apr 2015 09:26:13 -0400

> constituencies. Other groups may be added to this list as the set of use

This seems like a fine addition.

--Paul Hoffman

---

From: Rene Struik <[email-masked]>
Date: Thu, 09 Apr 2015 10:00:21 -0400

Hi Kepeng:

Some feedback (one remark, two small suggested text tweaks) below.

Best regards, Rene

> I copy the proposed texts here:
RS>> Just a remark (not a proposed change) to illustrate the importance of
this point: improper encodings have resulted in attacks in the past, 
see, e.g.,
N. Mavrogiannopoulos, F. Vercauteren, V. Velichkov, B. Preneel,
A Cross-Protocol Attack on the TLS Protocol, ACM CCS 2012.
<<RS
> work, message size and code size are to be considered whenever decisions
RS>> I suggest to change this paragraph slightly, as follows:
Since constrained environments are one of the primary targets for this 
work,
message size, code size, and computational cost are to be considered 
whenever
decisions are made.
NOTE: sometimes, small representation differences may have larger 
computational
impact, e.g, when dealing with security-related objects.
<<RS
> out of scope for the working group
RS>> I suggest to change this slightly, as follows:
Issues dealing with key management and binding of keys to identities are 
presently
out of scope and may only be considered after rechartering.
<<RS
> .
RS>> I can imagine some other "constrained cluster" groups also having 
an interest in this work, such
as 6TiSCH, 6lo, RoLL, etc. Perhaps, this is already captured under the 
last sentence, though.
<<RS
>
>
> ——————————————————————————————————————————————————
>
>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 9 Apr 2015 08:38:14 -0700

> -----Original Message-----
> From: Cose [mailto:[email-masked]] On Behalf Of Kepeng Li
> Sent: Wednesday, April 08, 2015 6:31 PM
> To: Paul Hoffman; Jim Schaad
> Cc: [email-masked]
> Subject: Re: [Cose] Charter Pull Request #2
>
work,
> message size and code size are to be considered whenever decisions are
> made.
>
out
> of scope for the working group.
>
cases
> is expanded.
>
>
> -----------------------------------
> ---------------
>
>

Yes - on the way to being done.

Jim

> >It's kind of unfair to expect people to know where the draft charter
> >is, or even what a "pull request" is. For those not in the know, the
> >draft charter is at:

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 9 Apr 2015 08:38:27 -0700

> From: Cose [mailto:[email-masked]] On Behalf Of Rene Struik
> Sent: Thursday, April 09, 2015 7:00 AM
> To: Kepeng Li; Paul Hoffman; Jim Schaad
> Cc: [email-masked]
> > Criteria that should be considered on making decisions in changing
> > from a JOSE to a CBOR encoding are:
> RS>> Just a remark (not a proposed change) to illustrate the importance
> RS>> of
> this point: improper encodings have resulted in attacks in the past, see,
e.g.,
> N. Mavrogiannopoulos, F. Vercauteren, V. Velichkov, B. Preneel, A Cross-
> Protocol Attack on the TLS Protocol, ACM CCS 2012.
> <<RS
> > - Providing new functionality that uses of JOSE did not require, but
> > are required for the new use cases.
> >
> > work, message size and code size are to be considered whenever
> > decisions are made.
work,
> whenever decisions are made.
> computational impact, e.g, when dealing with security-related objects.

This is something that people would not understand without an example.  (I
know that I am not sure what is intended here.)  If we have to have an
example then I am not sure that it makes sense.

I would however appreciate an example of what you mean because that might
suggest wording changes.

> <<RS
> >
> > Issues dealing with key management and binding of keys to identities
> > are out of scope for the working group
> presently out of scope and may only be considered after rechartering.

Your wording change suggests that we might consider this later.  I have no
intention of considering this.  I think this is work for the ACE and CORE
groups to deal with not for this group.   As such I don't believe the change
helps.

> <<RS
> > .
> >
> > The Working group will coordinate its progress with the ACE, DICE and
> > CoAP working groups to ensure that we are fulfilling the needs of
> > these constituencies. Other groups may be added to this list as the
> > set of use cases is expanded.
last
> sentence, though.

If we have other groups which we really think are going to need or use this
work, it makes sense to identify them sooner than later.  If we have them
identified then adding them now makes sense.

Jim

> <<RS
> >
> >
> > ----------------------------------
> ----------------
> >
> >

---

From: "Kepeng Li" <[email-masked]>
Date: Fri, 10 Apr 2015 00:24:55 +0800

>I would however appreciate an example of what you mean because that might

I assume that computational cost means CPU processing cost, memory cost,
etc.

Maybe Rene can further clarify.

Kind Regards
Kepeng

在 9/4/15 11:38 pm， "Jim Schaad" <[email-masked]> 写入:

>>see,

---

From: Rene Struik <[email-masked]>
Date: Thu, 09 Apr 2015 12:32:33 -0400

Hi Jim:

Please see below (RS2>> <<RS2).

Rene

> I would however appreciate an example of what you mean because that might
RS2>>
A simple example would be ECDSA signatures, where the signature (r,s) 
over a message is represented
as (r, 1/s) so as to avoid any inversions modulo the elliptic curve 
group size for verifiers, which could be
a useful trade-off in environments with lots of verifications relative 
to signatures, such as with Connected Vehicles
(IEEE 1609.2/DoT, EU initiatives). NOTE: this example is not meant at 
all to trigger a debate on whether this particular representation
convention should be pursued. It just illustrates that one should also 
consider trade-offs with computational
cost. Hence, the suggested wording change.
<<RS2
> groups to deal with not for this group.   As such I don't believe the change
RS2>> Perhaps. It is hard for me to keep track of which group should do 
what. What I do know
is that there are technical reasons to look at some of these topics. As 
an example, clever
representation of bindings of keys and identities may be crucial for, 
e.g., the join protocol with
6TiSCH. It may be okay to tackle this elsewhere, but question is why and 
whether there would
be sufficient critical mass to take on some of the micro-topics. To me, 
it seems that some representation
topics benefit from a system level perspective, even if these are not on 
the top of the list, due to
low-hanging fruit considerations.
<<RS

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 9 Apr 2015 12:18:45 -0700

> Sent: Thursday, April 09, 2015 9:33 AM
> To: Jim Schaad; 'Kepeng Li'; 'Paul Hoffman'
> Cc: [email-masked]
> >>> --------------------------------------------------------------------
> >>> --
> >>> -----
> >>> - Minimizing message size and code size should be considered (for
> >>> the constrained environments where we expect to use this).
> >>> - Improving security.
> >> RS>> Just a remark (not a proposed change) to illustrate the
> >> RS>> importance of
> >> N. Mavrogiannopoulos, F. Vercauteren, V. Velichkov, B. Preneel, A
> >> Cross- Protocol Attack on the TLS Protocol, ACM CCS 2012.
> >> <<RS
> >>> Since contrained environments are one of the primary targets for
> >>> this work, message size and code size are to be considered whenever
> >>> decisions are made.
> > This is something that people would not understand without an example.
> > (I know that I am not sure what is intended here.)  If we have to have
> > an example then I am not sure that it makes sense.
> >
> > I would however appreciate an example of what you mean because that
> > might suggest wording changes.
> RS2>>
> A simple example would be ECDSA signatures, where the signature (r,s) over a
> message is represented as (r, 1/s) so as to avoid any inversions modulo the
> elliptic curve group size for verifiers, which could be a useful trade-off in
> environments with lots of verifications relative to signatures, such as with
> Connected Vehicles (IEEE 1609.2/DoT, EU initiatives). NOTE: this example is
> not meant at all to trigger a debate on whether this particular representation
> convention should be pursued. It just illustrates that one should also consider
> trade-offs with computational cost. Hence, the suggested wording change.

Great that is the type of thing I was looking for.  I had not considered the issues of algorithm and algorithm encoding because I tend to think of that as being a separate step from the core message structure encoding.  I will think about this and see if I can offer a suggest later today on how to word this.

> >> are presently out of scope and may only be considered after rechartering.
> > Your wording change suggests that we might consider this later.  I
> > have no intention of considering this.  I think this is work for the ACE and
> CORE
> is that there are technical reasons to look at some of these topics. As an
> example, clever representation of bindings of keys and identities may be
> crucial for, e.g., the join protocol with 6TiSCH. It may be okay to tackle this
> elsewhere, but question is why and whether there would be sufficient critical
> mass to take on some of the micro-topics. To me, it seems that some
> representation topics benefit from a system level perspective, even if these
> are not on the top of the list, due to low-hanging fruit considerations.

Yes, there are a lot of problems in this space and there have been many different attempts to solve them.  Most of the solutions have had problems of one type or another.

Introduction - How do I know who you are the first time I see you.  I think, from the brief look at 6TiSCH that this is the main problem you are looking at.  There have been a lot of ways to go about this and none of them are generically good.

Certification - Given a trusted third party statement, how do you represent the binding of the key and the identity information.  This is basically the approach of X.509 certificates and OpenPGP keys.

There was yet another BOF at the last IETF on the first problem (ACME), as the web is currently  based on X.509 certificates it uses the them for the latter problem.

There are a lot of problems and a lot of solutions already in the world.  I would want to see something come to the fore as a single solution before worrying about that in this group.  Given that however, you might want to look at the JWT work that was done in the OAUTH working group.  That could encoded in COSE and potentially give you some of what you want.

I know that CORE/ACE are currently looking at doing some of their work with keys derived from DTLS sessions.  This does not give end to end, solutions, but can give point-to-point success.

> <<RS
> >
> >> <<RS
> >>> .
> >>>
> >>> The Working group will coordinate its progress with the ACE, DICE
> >>> and CoAP working groups to ensure that we are fulfilling the needs
> >>> of these constituencies. Other groups may be added to this list as
> >>> the set of use cases is expanded.
> >> RS>> I can imagine some other "constrained cluster" groups also
> >> RS>> having
> > If we have other groups which we really think are going to need or use
> > this work, it makes sense to identify them sooner than later.  If we
> > have them identified then adding them now makes sense.
> >
> > Jim
> >
> >
> >> <<RS
> >>>
> >>> ? 9/4/15 7:43 am, "Paul Hoffman" <[email-masked]> ??:
> >>>
> >>>> It's kind of unfair to expect people to know where the draft
> >>>> charter is, or even what a "pull request" is. For those not in the
> >>>> know, the draft charter is at:
> >>>>
> >>>> https://github.com/cose-spec/wg-charter/blob/master/draft-charter.m
> >>>> d and Jim's proposed changes are are:

---

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

Hi,  

I just have a question and a suggestion.

Sent from my iPhone

> On Apr 9, 2015, at 3:18 PM, "Jim Schaad" <[email-masked]> wrote:
> 
> 
> 
>>>>> from a JOSE to a CBOR

Shouldn't this be JOSE to COSE or JSON to CBOR?  Obviously language tweaks would be needed for the latter, but would be good to list that out explicitly for someone trying to figure what this is about.
>>>>> encoding are:
>>>>> of these constituencies.

The DIME chair came to the JOSE session as they need help and this may be part of what they need.  Is there a reason it's not listed?

Thanks,
Kathleen 

>>>>> Other groups may be added to this list as

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 10 Apr 2015 08:52:26 -0700

> From: Cose [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
> Sent: Friday, April 10, 2015 6:10 AM
> To: Jim Schaad
> Cc: Rene Struik; [email-masked]
> Shouldn't this be JOSE to COSE or JSON to CBOR?  Obviously language tweaks
> would be needed for the latter, but would be good to list that out
explicitly
> for someone trying to figure what this is about.

Yes - I changed to "JSON to CBOR".  

> >>>>> - Providing new functionality that uses of JOSE did not require,
> >>>>> but are required for the new use cases.
> >>>>>
> >>>>> this work, message size and code size are to be considered
> >>>> message size, code size, and computational cost are to be
> >>>> considered whenever decisions are made.
> >>> (I know that I am not sure what is intended here.)  If we have to
> >>> have an example then I am not sure that it makes sense.
> >>>
> >> over a message is represented as (r, 1/s) so as to avoid any
> >> inversions modulo the elliptic curve group size for verifiers, which
> >> could be a useful trade-off in environments with lots of
> >> verifications relative to signatures, such as with Connected Vehicles
> consider trade-offs with computational cost. Hence, the suggested wording
> change.
> >
> > Great that is the type of thing I was looking for.  I had not considered
the
> issues of algorithm and algorithm encoding because I tend to think of that
as
> being a separate step from the core message structure encoding.  I will
think
> about this and see if I can offer a suggest later today on how to word
this.
> >
> >> <<RS2
> >>>> <<RS
> >>>>> Issues dealing with key management and binding of keys to
> >>>>> identities are out of scope for the working group
> >>>> Issues dealing with key management and binding of keys to
> >>>> identities are presently out of scope and may only be considered
after
> rechartering.
> >> RS2>> Perhaps. It is hard for me to keep track of which group should
> >> RS2>> do
> >> what. What I do know
> >> is that there are technical reasons to look at some of these topics.
> >> As an example, clever representation of bindings of keys and
> >> identities may be crucial for, e.g., the join protocol with 6TiSCH.
> >> It may be okay to tackle this elsewhere, but question is why and
> >> whether there would be sufficient critical mass to take on some of
> >> the micro-topics. To me, it seems that some representation topics
> >> benefit from a system level perspective, even if these are not on the
top
> of the list, due to low-hanging fruit considerations.
> >
> > Yes, there are a lot of problems in this space and there have been many
> different attempts to solve them.  Most of the solutions have had problems
> of one type or another.
> >
> > Introduction - How do I know who you are the first time I see you.  I
think,
> from the brief look at 6TiSCH that this is the main problem you are
looking at.
> There have been a lot of ways to go about this and none of them are
> generically good.
> >
> > Certification - Given a trusted third party statement, how do you
represent
> the binding of the key and the identity information.  This is basically
the
> approach of X.509 certificates and OpenPGP keys.
> >
> > There was yet another BOF at the last IETF on the first problem (ACME),
as
> the web is currently  based on X.509 certificates it uses the them for the
> latter problem.
> >
> > There are a lot of problems and a lot of solutions already in the world.
I
> would want to see something come to the fore as a single solution before
> worrying about that in this group.  Given that however, you might want to
> look at the JWT work that was done in the OAUTH working group.  That could
> encoded in COSE and potentially give you some of what you want.
> >
> > I know that CORE/ACE are currently looking at doing some of their work
> with keys derived from DTLS sessions.  This does not give end to end,
> solutions, but can give point-to-point success.
> >
> >
> >> <<RS
> >>>
> >>>> <<RS
> >>>>> .
> >>>>>
> The DIME chair came to the JOSE session as they need help and this may be
> part of what they need.  Is there a reason it's not listed?

I did not think about them.  Previous efforts in that group have been CMS
oriented.   I have no problems with adding them in if you think we should.

Jim

> 
> Thanks,
> Kathleen
> 
> >>>>> Other groups may be added to this list as the set of use cases is
> >>>>> expanded.
> >>> If we have other groups which we really think are going to need or
> >>> use this work, it makes sense to identify them sooner than later.
> >>> If we have them identified then adding them now makes sense.
> >>>
> >>> Jim
> >>>
> >>>
> >>>> <<RS
> >>>>>
> >>>>>> charter is, or even what a "pull request" is. For those not in
> >>>>>> the know, the draft charter is at:
> >>>>>>
> >>>>>> https://github.com/cose-spec/wg-charter/blob/master/draft-
> charter
> >>>>>> .m d and Jim's proposed changes are are:

---

From: "Kepeng Li" <[email-masked]>
Date: Tue, 14 Apr 2015 20:15:13 +0800

>work, message size and code size are to be considered whenever decisions

I propose to remove the paragraph above, since it is redundant with the
second bullet in the previous paragraph.

Thanks,

Kind Regards
Kepeng

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 14 Apr 2015 10:12:15 -0700

> Sent: Tuesday, April 14, 2015 5:15 AM

I completely agree.  I missed that when I rolled it into the set of bullets.

Jim

> >-----------------------------------------------------------------------
> >---
> >-
> >Criteria that should be considered on making decisions in changing from
> >a JOSE to a CBOR encoding are:
> >are out of scope for the working group.
> >
> >CoAP working groups to ensure that we are fulfilling the needs of these
> >constituencies. Other groups may be added to this list as the set of
> >use cases is expanded.
> >
> >
> >---------------------------------
> -----------------
> >
> >

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 14 Apr 2015 10:44:06 -0700

> A simple example would be ECDSA signatures, where the signature (r,s) over
> a message is represented as (r, 1/s) so as to avoid any inversions modulo the

I have been thinking about this and think that it would not be a problem to include computational cost in this list, however I have been told that execution speed is frequently the looser when looking at the matrix the trio <power, memory, execution speed>.  While I recognize that computational complexity is not directly tied to speed, it can be measured in memory use as well, it would be more tied to selection of algorithms which the group is going to try and generally punt on to the groups that will be using the data format.  I don't want to include the text following "NOTE" and am not sure if you intended this to be included or not.

Jim

> elsewhere, but question is why and whether there would be sufficient
> critical mass to take on some of the micro-topics. To me, it seems that some
> charter.m

---

From: Rene Struik <[email-masked]>
Date: Tue, 14 Apr 2015 14:53:39 -0400

Hi Jim:

Indeed, the portion after "NOTE" was meant as explanatory note in my 
original email, thereby not forming part of the proposed tweak of the 
charter text. As to whether a particular metric would be weighed 
sufficiently during a WG's work, that is of later concern. My main 
objective was to have it included in charter terms.

Rene