Subject: [Cose] Charter State

From: "Jim Schaad" <[email-masked]>
Date: Tue, 14 Apr 2015 11:20:17 -0700

I would like to get Pull Request #2 rolled into the draft charter and then I
think we are ready to send it to the ADs and IESG for review.

Since it is my pull request I have not done the merge preferring that it be
done by one of the others who have permissions.  If I get a message saying
do the merge request I would be happy to pull the trigger on it.

Jim

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Apr 2015 11:32:15 -0700

On Apr 14, 2015, at 11:20 AM, Jim Schaad <[email-masked]> wrote:
> 
> I would like to get Pull Request #2 rolled into the draft charter and then I think we are ready to send it to the ADs and IESG for review.
>  
> Since it is my pull request I have not done the merge preferring that it be done by one of the others who have permissions.  If I get a message saying do the merge request I would be happy to pull the trigger on it.

There seemed to be general agreement, so I accepted the pull request.

Current version is at: https://github.com/cose-spec/wg-charter/blob/master/draft-charter.md

--Paul Hoffman

---

From: "Kepeng Li" <[email-masked]>
Date: Wed, 15 Apr 2015 09:59:26 +0800

Thanks Paul.

There are two other changes we might want to incorporate:

1) Proposal from Goran:
http://www.ietf.org/mail-archive/web/cose/current/msg00027.html

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

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

(2) Proposal from Kathleen:

http://www.ietf.org/mail-archive/web/cose/current/msg00077.html

OLD:
The Working Group will coordinate its progress with the ACE, DICE and CoRE
working groups to ensure that we are fulfilling the needs of these
constituencies.

NEW:
The Working Group will coordinate its progress with the ACE, DICE, CoRE
and DIME
working groups to ensure that we are fulfilling the needs of these
constituencies.

Thanks,

Kind Regards
Kepeng

在 15/4/15 2:32 am， "Paul Hoffman" <[email-masked]> 写入:

>> I would like to get Pull Request #2 rolled into the draft charter and
>>then I think we are ready to send it to the ADs and IESG for review.
>>  
>> Since it is my pull request I have not done the merge preferring that
>>it be done by one of the others who have permissions.  If I get a
>>message saying do the merge request I would be happy to pull the trigger
>>on it.
>
>Current version is at:
>https://github.com/cose-spec/wg-charter/blob/master/draft-charter.md
>
>--Paul Hoffman
>
>_______________________________________________
>Cose mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cose

---

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

> -----Original Message-----
> From: Cose [mailto:[email-masked]] On Behalf Of Kepeng Li
> Sent: Tuesday, April 14, 2015 6:59 PM
> To: Paul Hoffman; Jim Schaad
> Cc: [email-masked]
> Subject: Re: [Cose] Charter State
>
> Thanks Paul.
>
from
> JOSE, expressed in CBOR"
from
> JOSE and optimizations for constrained device processing, expressed in
CBOR”

I am agnostic about including this change.  We now are much more constrained
device focused later so it might not be needed.

> The Working Group will coordinate its progress with the ACE, DICE, CoRE
and
> DIME working groups to ensure that we are fulfilling the needs of these
> constituencies.

I am not sure that DIME is a reasonable group to be coordinating with since
it is not clear that this would be the solution space they are going to
operate in.  It is true that this need something along these lines, but what
they need first is to get someone who has good knowledge of what can be done
in the group first.  Given that this is major (telecom) vendors, using CMS
might be a better fit for this

The other question if we expand this list here rather than in the wiki is
the set of groups that Rene Struik though that might be included here such
as "6TiSCH, 6lo, RoLL, etc" which seem to be much closer to the types of
groups that might use this specification going forward.

At this point, I think I would go with the list we have and start adding
more groups to the wiki.

Jim

> >>message saying do the merge request I would be happy to pull the
> >>trigger on it.
> >

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 14 Apr 2015 22:16:31 -0400

Sent from my iPhone

> On Apr 14, 2015, at 10:10 PM, "Jim Schaad" <[email-masked]> wrote:
> 
> 
> 

I'm fine with that approach.  My point in bringing up DIME was more that they need help and this *could* help them, but work needs to be done to figure out what they need at this point.  I brought it up just in case it's relevant to COSE.

Thanks,
Kathleen

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 21 Apr 2015 15:32:09 -0700

The date change proposed by me has been merged into the draft.

I believe that we can now consider the charter discussion to be complete unless anyone else has a big issue they want to bring up.

Kathleen:  Can we get this to move forward into the IESG?

Jim

> From: Cose [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
> Sent: Tuesday, April 14, 2015 7:17 PM
> To: Jim Schaad
> Cc: Kepeng Li; Paul Hoffman; [email-masked]
> > CBOR
> > I am agnostic about including this change.  We now are much more
> > constrained device focused later so it might not be needed.
> >
> >>
> >> The Working Group will coordinate its progress with the ACE, DICE and
> >> CoRE working groups to ensure that we are fulfilling the needs of
> >> these constituencies.
> >>
> >> NEW:
> >> DIME working groups to ensure that we are fulfilling the needs of
> >> these constituencies.
> >
> > I am not sure that DIME is a reasonable group to be coordinating with
> > since it is not clear that this would be the solution space they are
> > going to operate in.  It is true that this need something along these
> > lines, but what they need first is to get someone who has good
> > knowledge of what can be done in the group first.  Given that this is
> > major (telecom) vendors, using CMS might be a better fit for this
> >
> > The other question if we expand this list here rather than in the wiki
> > is the set of groups that Rene Struik though that might be included
> > here such as "6TiSCH, 6lo, RoLL, etc" which seem to be much closer to
> > the types of groups that might use this specification going forward.
> >
> > At this point, I think I would go with the list we have and start
> > adding more groups to the wiki.
> 
> I'm fine with that approach.  My point in bringing up DIME was more that they
> need help and this *could* help them, but work needs to be done to figure
> out what they need at this point.  I brought it up just in case it's relevant to
> COSE.
> 
> Thanks,
> Kathleen
> >
> > Jim
> >
> >>
> >>
> >> Thanks,
> >>
> >> Kind Regards
> >> Kepeng
> >>
> >> ? 15/4/15 2:32 am, "Paul Hoffman" <[email-masked]> ??:
> >>
> >>>> I would like to get Pull Request #2 rolled into the draft charter
> >>>> and then I think we are ready to send it to the ADs and IESG for review.
> >>>>
> >>>> Since it is my pull request I have not done the merge preferring
> >>>> that it be done by one of the others who have permissions.  If I
> >>>> get a message saying do the merge request I would be happy to pull
> >>>> the trigger on it.
> >>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 22 Apr 2015 12:27:17 -0400

Hi,

I am assuming the current charter text is at the link:
https://github.com/cose-spec/wg-charter/blob/master/draft-charter.md

I have some proposed changes that I think help with readability.  Let me
know if these are ok and I'll put in the charter for IESG review.  All of
the charter text is included, broken out by sections to show edits.  In
some cases, there is a Note: following a change with assumptions I was
making in case they were not correct assumptions.

Old: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).
New:
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 COSE was to reuse functionality
from the JOSE working group using the CBOR data representation as it is
more amenable to constrained nodes and constrained node networks (RFC 7228).

Old:
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:
The JOSE working group recently completed producing representations for
cryptographic keys, message authentication (MACs), encryption, and digital
signatures, using JSON representation. COSE will rely on the JOSE
registries, and will be expand them with additional information when
necessary.

Note: you may have other reasons besides efficiency.

Old:
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.
New:
The resulting formats will not be cryptographically convertible from or to
JOSE formats. This lack of a need for bit-for-bit compatibility will enable
some simplification in the adaptation process.

Old:

Criteria that should be considered on making decisions in changing from a
JSON to a CBOR encoding are:

   -

   Keeping the current JOSE paradigms and formatting where feasible.
   -

   Minimizing message size, code size and computational complexity 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.

New:

Criteria that should be considered in the decision making process, changing
from JSON to CBOR encoding include:

   -

   Maintain the current JOSE paradigms and formatting where feasible.
   -

   Minimize message size, code size, and computational complexity to suit
   constrained environments, where this is expected to  be used.
   -

   Improve security
   -

   Provide new functionality for additional use cases that were not
   required for JOSE.

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

Note: I am assuming you really want to out-of scope all key management and
not just issues?

And I don't see any need to tweak the rest of the text:

The Working group will coordinate its progress with the ACE, DICE and CORE
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.

The WG will have two deliverables:

   - a standards-track specification covering the same cryptographic
   formats from JOSE, with optimizations for constrained device processing,
   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.

I'd love it if you can keep to the milestones projected :-)

Thanks.
Kathleen

On Tue, Apr 21, 2015 at 6:32 PM, Jim Schaad <[email-masked]> wrote:

> I believe that we can now consider the charter discussion to be complete
> unless anyone else has a big issue they want to bring up.
>

-- 

Best regards,
Kathleen

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 22 Apr 2015 09:41:38 -0700

Be my guest to make the changes.

Jim

From: Cose [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Wednesday, April 22, 2015 9:27 AM
To: Jim Schaad
Cc: [email-masked]
Subject: Re: [Cose] Charter State

Hi,

I have some proposed changes that I think help with readability.  Let me know if these are ok and I'll put in the charter for IESG review.  All of the charter text is included, broken out by sections to show edits.  In some cases, there is a Note: following a change with assumptions I was making in case they were not correct assumptions.

Old: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).

New:

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 COSE was to reuse functionality from the JOSE working group using the CBOR data representation as it is more amenable to constrained nodes and constrained node networks (RFC 7228).

Old:

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:

The JOSE working group recently completed producing representations for cryptographic keys, message authentication (MACs), encryption, and digital signatures, using JSON representation. COSE will rely on the JOSE registries, and will be expand them with additional information when necessary.

Old:

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.

New: 

The resulting formats will not be cryptographically convertible from or to JOSE formats. This lack of a need for bit-for-bit compatibility will enable some simplification in the adaptation process.

Old:

Criteria that should be considered on making decisions in changing from a JSON to a CBOR encoding are:

·      Keeping the current JOSE paradigms and formatting where feasible.

·      Minimizing message size, code size and computational complexity 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.

New: 

Criteria that should be considered in the decision making process, changing from JSON to CBOR encoding include:

·      Maintain the current JOSE paradigms and formatting where feasible.

·      Minimize message size, code size, and computational complexity to suit constrained environments, where this is expected to  be used.

·      Improve security

·      Provide new functionality for additional use cases that were not required for JOSE. 

Old:

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

New:

Key management and binding of keys to identities are out of scope for the working group.

Note: I am assuming you really want to out-of scope all key management and not just issues?

The Working group will coordinate its progress with the ACE, DICE and CORE 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.

*	a standards-track specification covering the same cryptographic formats from JOSE, with optimizations for constrained device processing, 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.

Thanks.
Kathleen

Jim

 

-- 

Best regards,

Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 22 Apr 2015 12:54:38 -0400

Great, are others ok with the changes?  If so, I'll get it rolling.

On Wed, Apr 22, 2015 at 12:41 PM, Jim Schaad <[email-masked]> wrote:

> *From:* Cose [mailto:[email-masked]] *On Behalf Of *Kathleen
> Moriarty
> *Sent:* Wednesday, April 22, 2015 9:27 AM
> *To:* Jim Schaad
>
> *Cc:* [email-masked]
> *Subject:* Re: [Cose] Charter State
>
>
>
> Hi,
>
>
>
> ·      Minimizing message size, code size and computational complexity
> should be considered (for the constrained environments where we expect to
> use this).
>
> ·      Improving security
>
> Criteria that should be considered in the decision making process,
> changing from JSON to CBOR encoding include:
>
> ·      Minimize message size, code size, and computational complexity to
> suit constrained environments, where this is expected to  be used.
>
> ·      Improve security
>

-- 

Best regards,
Kathleen

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Apr 2015 10:01:32 -0700

> Great, are others ok with the changes?  If so, I'll get it rolling.

They look fine to me, as does rolling.

--Paul Hoffman

---

From: "Kepeng Li" <[email-masked]>
Date: Wed, 22 Apr 2015 10:47:48 +0800

Fine with me.

Thanks.

Kind Regards
Kepeng

在 23/4/15 1:01 am， "Paul Hoffman" <[email-masked]> 写入:

>On Apr 22, 2015, at 9:54 AM, Kathleen Moriarty
><[email-masked]> wrote:

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 Apr 2015 20:02:54 +0200

s/will be expand them/will expand them/

Looks fine otherwise, and I also agree with rolling this now. 
Thanks for the clarifying! 

Sent from my iPad while stuck in the German train driver strike

> On 22.04.2015, at 18:27, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi,
> 
> Minimizing message size, code size and computational complexity 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.
> 
> New:
> Minimize message size, code size, and computational complexity to suit constrained environments, where this is expected to  be used.
> 
> Improve security
> 
> Provide new functionality for additional use cases that were not required for JOSE. 
> 
> Old:
> a standards-track specification covering the same cryptographic formats from JOSE, with optimizations for constrained device processing, expressed in CBOR;
> registration for algorithms (such as AES-CCM-8) that are appropriate for constrained environments.

---

From: ⌘ Matt Miller <[email-masked]>
Date: Wed, 22 Apr 2015 13:01:41 -0600

On 4/21/15 8:47 PM, Kepeng Li wrote:
> Kind Regards Kepeng

+1

SHIPIT!

- -- 
- - m&m

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 22 Apr 2015 15:04:34 -0400

Great, thank you!

I'll move it forward to the next review stage.  If something else is spotted, it can be fixed.

Thanks,
Kathleen 

Sent from my iPhone

> On Apr 22, 2015, at 3:01 PM, ⌘ Matt Miller <[email-masked]> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> 
> iQEcBAEBCgAGBQJVN/AVAAoJEDWi+S0W7cO1/A8IAJrubZh6DL5kVuuebLp5NIDd
> myV3dqb7dk3kdb6Rl53edawZSrPJUXo/QV/szfPwizEIfKVGHi9FGvBcsSiVZHSK
> LAzseprJiB2BmN8aC1lfHrUs9dJTfy2psJfVAqXbpTkioLUR3y0Y03EAnayRvNhD
> tsjHrpOim1xDmY2N9ouOg9KbbH5tckmu+PyepuwYTjioUS9P0uUvhs35sDdzc3rV
> fhM9JxZAPLZSd42hIBokLp1n3L/0UQ2cfrr04IU3fJbZFVbBdbJYHL11mukXwoPG
> RZX4hhQfGxdVyS6m1TmltbReEJz22aZDb4Y9EwsMlUxjkzOh6v4gGOqQF/W/SQc=
> =zhUj
> -----END PGP SIGNATURE-----

---

From: Göran Selander <[email-masked]>
Date: Wed, 22 Apr 2015 19:23:32 +0000

Looks fine. 

About the constrained-appropriate algorithms: is the intention to consult CFRG? If so, maybe would be good to get that ball rolling too soon. 

Thanks,
Göran

> On 22 apr 2015, at 18:54, Kathleen Moriarty <[email-masked]> wrote:
>

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 22 Apr 2015 12:43:35 -0700

In order to get the CFRG pointed in the right direction, it is necessary to give it some input.   To that end I would suggest we start with doing a survey of three questions:

1.        What type of algorithms are needed?  (key agreement, key transport, signature, hash, MAC, KDF, etc)

2.       What are the constraints we really care about?

3.       What algorithms are we currently using today for those purposes?

Jim

From: Göran Selander [mailto:[email-masked]] 
Sent: Wednesday, April 22, 2015 12:24 PM
To: Kathleen Moriarty
Cc: Jim Schaad; [email-masked]
Subject: Re: [Cose] Charter State

Looks fine. 

Thanks,

Göran

Jim

Cc: [email-masked]

Hi,

New:

Old:

New:

Old:

New: 

Old:

·      Improving security

New: 

·      Improve security

Old:

New:

Thanks.
Kathleen

Jim

 

-- 

Best regards,

Kathleen

-- 

Best regards,

Kathleen

---

From: Göran Selander <[email-masked]>
Date: Thu, 23 Apr 2015 06:47:50 +0000

For the use cases I have in mind: key transport, KDF, encryption/AEAD, hash and signature. But the main concern is around signatures.

1. ECDSA size of signature at 112-128 bits security is of the order of 60 bytes which is a lot compared to 8 bytes truncated MAC. It would be good to have a recommendation of a signature algorithm with message recovery, such as ECPVS (which has some IPR, some of which is expiring in a few years) or other.

2. A combined symmetric key encryption + signature is needed for point-multipoint settings.

The charter says "Minimizing message size, code size and computational complexity”.  In order of importance for signatures I’d say message size, computational complexity, code size.

The default algorithms are those specified by CoAP (secp256r1 for ECDSA)

Jim

From: Göran Selander [mailto:[email-masked]]
Sent: Wednesday, April 22, 2015 12:24 PM
To: Kathleen Moriarty
Cc: Jim Schaad; [email-masked]<mailto:[email-masked]>
Subject: Re: [Cose] Charter State

Looks fine.

Thanks,
Göran

On 22 apr 2015, at 18:54, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:
Great, are others ok with the changes?  If so, I'll get it rolling.

On Wed, Apr 22, 2015 at 12:41 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
Be my guest to make the changes.

Jim

From: Cose [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kathleen Moriarty
Sent: Wednesday, April 22, 2015 9:27 AM
To: Jim Schaad

Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Cose] Charter State

Hi,

Old:

Old:

Old:

·      Improving security

·      Improve security

Thanks.
Kathleen

On Tue, Apr 21, 2015 at 6:32 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
The date change proposed by me has been merged into the draft.

Jim

> From: Cose [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kathleen Moriarty
> Cc: Kepeng Li; Paul Hoffman; [email-masked]<mailto:[email-masked]>
> > On Apr 14, 2015, at 10:10 PM, "Jim Schaad" <[email-masked]<mailto:[email-masked]>>
> wrote:
> >
> >
> >
> >> From: Cose [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kepeng Li
> >> Cc: [email-masked]<mailto:[email-masked]>
> >> ? 15/4/15 2:32 am, "Paul Hoffman" <[email-masked]<mailto:[email-masked]>> ??:
> >>
> >>> On Apr 14, 2015, at 11:20 AM, Jim Schaad <[email-masked]<mailto:[email-masked]>>
> wrote:
> >>>>
> >>> [email-masked]<mailto:[email-masked]>
> >> [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

--

Best regards,
Kathleen

--

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Apr 2015 10:22:07 +0100

Please be aware tha CFRG are currently very busy with selecting
and documenting additional curves and associated signature
mechanisms. If COSE needs CFRG help, you should really try to
minimise what's needed.

You could minimise that to zero by only using well-worn crypto.

But if COSE needs to go beyond that (my I hope is it does not),
then you ought be ready for delay - like any other group CFRG
has limited bandwidth bounded by volunteer cycles.

S.

---

From: Göran Selander <[email-masked]>
Date: Sat, 25 Apr 2015 05:16:34 +0000

Hi Stephen,

I asked Kenny Patterson in Dallas about signature algorithm with message
recovery suitable for embedded devices and he recommended me to send an
email to CFRG after the EC signature discussion had begun (and be prepared
for delays etc.).

When the discussion appeared in COSE, I thought it would be better (e.g.
from a "minimize disturbance” point of view) that someone contacted CFRG
on behalf of COSE rather than me sending a personal email. Do you agree?

Göran

On 2015-04-23 11:22, "Stephen Farrell" <[email-masked]> wrote:

>> In order to get the CFRG pointed in the right direction, it is
>>necessary to give it some input.   To that end I would suggest we start
>>with doing a survey of three questions:
>> 
>> 
>> 1.        What type of algorithms are needed?  (key agreement, key
>>transport, signature, hash, MAC, KDF, etc)
>> 
>> For the use cases I have in mind: key transport, KDF, encryption/AEAD,
>>hash and signature. But the main concern is around signatures.
>> 
>> 1. ECDSA size of signature at 112-128 bits security is of the order of
>>60 bytes which is a lot compared to 8 bytes truncated MAC. It would be
>>good to have a recommendation of a signature algorithm with message
>>recovery, such as ECPVS (which has some IPR, some of which is expiring
>>in a few years) or other.
>> 
>> The charter says "Minimizing message size, code size and computational
>>complexity”.  In order of importance for signatures I’d say message
>>size, computational complexity, code size.
>> 
>> 
>> 
>> About the constrained-appropriate algorithms: is the intention to
>>consult CFRG? If so, maybe would be good to get that ball rolling too
>>soon.
>> 
>> Thanks,
>> Göran
>> 
>> On 22 apr 2015, at 18:54, Kathleen Moriarty
>><[email-masked]<mailto:[email-masked]
>>>> wrote:
>> On Wed, Apr 22, 2015 at 12:41 PM, Jim Schaad
>><[email-masked]<mailto:[email-masked]>> wrote:
>> I have some proposed changes that I think help with readability.  Let
>>me know if these are ok and I'll put in the charter for IESG review.
>>All of the charter text is included, broken out by sections to show
>>edits.  In some cases, there is a Note: following a change with
>>assumptions I was making in case they were not correct assumptions.
>> 
>>data model more amenable to constrained nodes and constrained node
>>networks (RFC 7228).
>> New:
>> Concise Binary Object Representation (CBOR, RFC 7049) is a concise
>>version of the JSON data model. One motivation for COSE was to reuse
>>functionality from the JOSE working group using the CBOR data
>>representation as it is more amenable to constrained nodes and
>>constrained node networks (RFC 7228).
>> 
>> Old:
>>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:
>>cryptographic keys, message authentication (MACs), encryption, and
>>digital signatures, using JSON representation. COSE will rely on the
>>JOSE registries, and will be expand them with additional information
>>when necessary.
>> 
>> 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.
>> New:
>> The resulting formats will not be cryptographically convertible from or
>>to JOSE formats. This lack of a need for bit-for-bit compatibility will
>>should be considered (for the constrained environments where we expect
>>to use this).
>> 
>> ·      Improving security
>> 
>> ·      Minimize message size, code size, and computational complexity
>>to suit constrained environments, where this is expected to  be used.
>> 
>> ·      Improve security
>> 
>> The Working group will coordinate its progress with the ACE, DICE and
>>CORE working groups to ensure that we are fulfilling the needs of these
>>   *   a standards-track specification covering the same cryptographic
>>   *   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.
>> 
>> 
>> On Tue, Apr 21, 2015 at 6:32 PM, Jim Schaad
>><[email-masked]<mailto:[email-masked]>> wrote:
>> I believe that we can now consider the charter discussion to be
>>complete unless anyone else has a big issue they want to bring up.
>> 
>>> From: Cose 
>>>[mailto:[email-masked]<mailto:[email-masked]>] On Behalf
>>>Of Kathleen Moriarty
>>>> On Apr 14, 2015, at 10:10 PM, "Jim Schaad"
>>>><[email-masked]<mailto:[email-masked]>>
>>> wrote:
>>>>
>>>>
>>>>
>>>>> From: Cose 
>>>>>[mailto:[email-masked]<mailto:[email-masked]>] On
>>>>>Behalf Of Kepeng Li
>>>>> ? 15/4/15 2:32 am, "Paul Hoffman"
>>>>><[email-masked]<mailto:[email-masked]>> ??:
>>>>>
>>>>>> On Apr 14, 2015, at 11:20 AM, Jim Schaad
>>>>>><[email-masked]<mailto:[email-masked]>>
>>> wrote:
>>>>>>>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Apr 2015 13:12:10 +0100

> on behalf of COSE rather than me sending a personal email. Do you agree?

I wouldn't say it'll make that much difference to the timing in this
case, but sure, once there's a COSE WG and the chairs figure there's
rough consensus on just what crypto stuff is needed, it'll be good to
get a question (or set of questions) sent to CFRG from the WG.

In the past, CFRG regretted it when they answered what they thought
was the question asked, when that in fact turned out not to be the
right question to answer for a WG. People who care and are able, can
of course go get involved on the CFRG list directly to move the work
forward.

S.