Subject: [COSE] Comments for draft-ietf-cose-msg-03

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Aug 2015 18:22:37 +0200

Hi Jim, Hi all,

out of curiosity I have been reading through the latest version of the
COSE draft and ran into a few questions.

* MTI

Section 1.6 is supposed to define mandatory-to-implement algorithms but
actually doesn't say what those are.

I personally don't believe it is useful to define MTI algorithms for
such a document that will most likely be used in a variety of different
environments. I would nevertheless be interested to know what the MTI
algorithms should be (from your point of view).

* Examples

As most people I also look at the examples first and would have
appreciated a bit more explanation. So, help me understand them.

Take Appendix C.1.1 "Shared Secret Direct MAC". I assume that the
'direct shared secret' means that the sender of the message and the
receiver share a symmetric key.

What does "File name: Mac-04" mean?

Just to make sure that I understand the structure correctly I added
comments inline:

   {
     1: 3,  --> msg_type is COSE_mac
     2: h'a1016f4145532d434d41432d3235362f3634',

   --> protected header fields
    When I use a CBOR decoder I get the value of
'"\xA1\x01oAES-CMAC-256/64".
    Is that really the encoding for the algorithm id?

     4: h'546869732069732074686520636f6e74656e742e',
     --> payload of the string "This is the content."

     10: h'd9afa663dd740848', --> tag which contains the MAC value.
     9: [ --> recipients
       {
         3: {
           1: -6,
           4: h'6f75722d736563726574'
         }
       }
     ]
   }

Section 6 talks about recipients and says:

"
   recipients  contains the recipient information.  See the description
      under COSE_Encryption for more info.
"

When I look for more info in Section 5 then I do not find a lot.
Why is the field mandatory? What is the meaning of it in this example?

For an IoT context I would imagine that the algorithm and the key has
been agreed between the sender and the receiver using some key
management protocol and the appropriate example would be something like:

   {
     1: 3,
     2: {4: 1,6: 1},
     4: "This is the content.",
     10: h'd9afa663dd740848'
   }

(Note that I don't really know whether this is the encoding you envision
for the header parameters.)

Minor issues:

* You write: "CBOR extended the data model of the JavaScript Object
Notation (JSON) by allowing for binary data among other changes."

Is 'data model' the right term here? I think we are talking about encoding.
For a more detailed treatment of what a data model is take a look at RFC
3444.

* You write:
"
   o  The author did not always agree with some of the decisions made by
      the JOSE working group.  Many of these decisions have been re-
      examined, and where it seems to the author to be superior or
      simpler, replaced.
"

For a working group draft it does not matter whether the author agrees
or disagrees. I would suggest to remove this paragraph.

* SMIME/CMS

I would remove references to CMS and S/MIME since they are most likely
only helpful to a very small audience.

Ciao
Hannes

---

From: Justin Richer <[email-masked]>
Date: Thu, 27 Aug 2015 13:15:12 -0400

> or disagrees. I would suggest to remove this paragraph.

I agree with Hannes, this kind of text has no business in a working group draft. Jim, please remove it in the next draft. (I’ll file an issue in a moment.)

 — Justin

> On Aug 27, 2015, at 12:22 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Jim, Hi all,
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 27 Aug 2015 13:37:04 -0700

> -----Original Message-----
> From: COSE [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Thursday, August 27, 2015 9:23 AM
> To: [email-masked]
> Subject: [COSE] Comments for draft-ietf-cose-msg-03
> 
> Hi Jim, Hi all,
> 
> out of curiosity I have been reading through the latest version of the COSE draft
> and ran into a few questions.

You might also look at the WIP draft on github as it has a change from using maps to arrays at the top level.  This makes the code slightly different and provides a small decrease in message sizes.

> I personally don't believe it is useful to define MTI algorithms for such a
> document that will most likely be used in a variety of different environments. I
> would nevertheless be interested to know what the MTI algorithms should be
> (from your point of view).

I agree with the idea of it not being useful to define the MTI algorithms.  I am at a loss why you think it should be given that the first paragraph includes the following sentence:

However, we have elected not to specify a set of mandatory algorithms in this document.

That being said.  If I were to think about a mandatory set it would probably look something like:

* Content Encryption: either AES-GCM or AES-CCM depending on if you think that small devices are the target market.  AES-CCM is easier to implement, but it prohibits any streaming encryption operation as you need to know the length of the output before you start.
* Key Management: Probably ECDH either directly or wrapped with AES-KW.  The first allows for low grade origination if one does static-static so it would be useful both for encryption and MACs
* MAC algorithm - HMAC-Sha256
* Signature Algorithm - ECDSA

The latter three make the assumption that SHA-256 is a supported hash algorithm.  If that is not doable then one would need to re-look at the outputs.  I am not ready to jump ship to the new algorithms, but might soon be willing to do so with the new ECDH curve and signatures.

> 
> * Examples
> 
> As most people I also look at the examples first and would have appreciated a
> bit more explanation. So, help me understand them.
> 
> Take Appendix C.1.1 "Shared Secret Direct MAC". I assume that the 'direct
> shared secret' means that the sender of the message and the receiver share a
> symmetric key.

Yes this is correct.

> What does "File name: Mac-04" mean?

This is the name of the file in the examples project up on github (see first paragraph of appendix C).

> 
> Just to make sure that I understand the structure correctly I added comments
> inline:
> 
>    {
>     When I use a CBOR decoder I get the value of '"\xA1\x01oAES-CMAC-256/64".

Yes.  The string will be shortened to an integer when it gets assigned.  Until then I am using the string for the identifier.  At that point it would be something like 'a101XX'  where XX would be an encoded integer of the correct value.  This is expected to be done relatively soon.

> Why is the field mandatory? What is the meaning of it in this example?

For MACs, one still needs to do some type management for the recipient to identify the key that is going to be used to compute the MAC for verification.  This is not restricted to just having a pre-shared secret.  Instead one can derive the secret by using, for example, ECDH-SS.  Part of the question here is if anonymous MAC is interesting (i.e. just encrypting the MAC key for the recipient with RSA) or if low grade origination is needed.  Even for low-grade origination the direct, derived from direct and ECDH-SS direct recipient types would all give the needed origination proofs.

> 
> For an IoT context I would imagine that the algorithm and the key has been
> agreed between the sender and the receiver using some key management
> protocol and the appropriate example would be something like:
> 
>    {
>      1: 3,
>      2: {4: 1,6: 1},
> (Note that I don't really know whether this is the encoding you envision for the
> header parameters.)

There is an on-again, off-again discussion about making direct key management privileged in terms of key management.  Personally, I am against this as I would prefer to see everything be uniform in all cases and I don't know that you win enough by making things special.  Part of the question is are you ever going to do anything except direct key.   >From a security point of view, I would argue that you are much better off doing a KDF on a shared secret and using that on a per message basis rather than having a key that is used until some external event occurs.  

I would also tend to make the same argument about making the algorithm be implicit rather than explicit.  While possible, I don't know that this is really a good idea.  I have generally found it to be a problem latter on in the process.  However, the implementations that I have done would allow for that to happen.  I just don't care for it as a suggested way to travel.

This means that I would be looking more at
{  1:3,
   2:{1:15},
   4:"This is the content.",
   10:h'd9afa663dd740848',
   9:[{ 3:{1:-6}}]
}

I am not sure what you are looking at for the two parameters that you included in your example.  If they are just place holders then you could include them as well.  I omit the KID parameter from the recipient structure since that can be implied relatively easily if you only have one dialog going on between the two entities.  If you have multiple dialogs then include a KID is useful.

> 
> Minor issues:
> 
> * You write: "CBOR extended the data model of the JavaScript Object Notation
> (JSON) by allowing for binary data among other changes."
> 
> For a more detailed treatment of what a data model is take a look at RFC 3444.

I took the term from RFC 7049 in the introduction section.  Different people have different definitions of data model but I think that this is a legal one.

"The underlying data model is an extended version of the JSON data model [RFC4627]."

> For a working group draft it does not matter whether the author agrees or
> disagrees. I would suggest to remove this paragraph.

Yes - It was originally written to be an individual draft not a working group draft.  I will look at doing a re-write because for people who come into this from the JOSE world, they may want some explanation about why things are different.

> 
> 
> * SMIME/CMS
> 
> I would remove references to CMS and S/MIME since they are most likely only
> helpful to a very small audience.

Will look at.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 28 Aug 2015 01:17:10 +0200

Great discussion.

My two yens for now:

> You might also look at the WIP draft on github as it has a change from using maps to arrays at the top level.  

I'm curious: What keeps us from working with that as the WG draft?
I think we would benefit from reducing the distance between the editor's
draft and the WG draft.

(Next, I'd like to get rid of the msg_type.)

> * Signature Algorithm - ECDSA

There is little point in having an "MTI" signature algorithm without
also specifying the curve.  (And you mentioned the GCM-CCM split.)

Oh, and:

> key management

I think we'll all benefit from not using that word any more in this WG.

>> Is 'data model' the right term here? I think we are talking about encoding.

No, we are indeed talking about the data model.
It's JSON's data model that does not provide for binary data (= byte
strings).
(Yes, that also means there is no encoding for binary data in JSON, but
that is ancillary to binary data not being there in the first place.)

>> For a more detailed treatment of what a data model is take a look at RFC 3444.

That is still the same kind of data model, except that in RFC 3444 it is
used for a specific data model and contrasted to the information model.
 Here we are talking about the generic data model of JSON as compared to
CBOR.  (The information models represented in these data models could
still be the same, e.g., by base64-encoding some information in JSON
while keeping it in its natural form in CBOR.)

Grüße, Carsten

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 27 Aug 2015 20:29:43 -0700

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Thursday, August 27, 2015 4:17 PM
> To: Jim Schaad <[email-masked]>
> Cc: 'Hannes Tschofenig' <[email-masked]>; [email-masked]
> Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03
> 
> Great discussion.
> 
> My two yens for now:
> 
> I think we would benefit from reducing the distance between the editor's draft
> and the WG draft.

I am not sure what I can do to point people to the github draft more than is already done.

The only behavior that I can change is to publish more often in terms of reducing the distance between drafts.  But I am currently thinking in terms of doing this every 2-3 weeks.  I don't know that more frequently is helpful.

> There is little point in having an "MTI" signature algorithm without also
> specifying the curve.  (And you mentioned the GCM-CCM split.)

Yeah, I kind of did that in terms of saying that I was not ready to jump to the new CFRG curves.  I was kind of assuming it would be P256 for size reasons.

> I think we'll all benefit from not using that word any more in this WG.

I will keep trying, but this is the term that is ingrained in my vocabulary.  It is not in the document anymore.

Jim

> It's JSON's data model that does not provide for binary data (= byte strings).
> (Yes, that also means there is no encoding for binary data in JSON, but that is
> ancillary to binary data not being there in the first place.)
> 
> That is still the same kind of data model, except that in RFC 3444 it is used for a
> specific data model and contrasted to the information model.
> CBOR.  (The information models represented in these data models could still be
> the same, e.g., by base64-encoding some information in JSON while keeping it in
> its natural form in CBOR.)
> 
> Grüße, Carsten

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 28 Aug 2015 08:13:36 +0200

...
>      Is that really the encoding for the algorithm id?

Ha! That one made me think twice and read the fine-print.

a1016f4145532d434d41432d3235362f3634 (which indeed decodes to
"\xA1\x01oAES-CMAC-256/64")

is a binary representation of the protected header which is a CBOR 
structure itself, so if you put a1016f4145532d434d41432d3235362f3634 in 
a CBOR decoder you get:

{1: "AES-CMAC-256/64"}

... which makes perfect sense.

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 28 Aug 2015 08:15:58 +0200

Hi Jim,

a few nitpicks from me:

Section 1.4  "... choice data items ..." should be "... chose data items 
..."

Section 3. 3rd para  "a common connical encoding" should be "a common 
cannonical encoding" i guess

Section 4:
I'd rather reference the definition of 'Headers' instead of the 
definition of 'protected' and 'unprotected' in the last two CDDLs. Same 
goes for sections 5 and 6.

Section 5:
"In COSE, the same techniques and structures for encrypting both the 
plain text and the keys used to protect the text."

This sentence is missing a word. Perhaps "... keys are used ..."?

Section 8:
"in the worst case it because the same as doing a singature with appendix. "

s/because/becomes/

Section 12.1.2
"One unpredictable manner than can be used is to use the HKDF function 
to generate the IV."

s/than/that/

Appendix B, Second bullet list jumps from Level 1 to Level 3 for no 
apparent reason (or I'm just not getting it).

Regards,
Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 28 Aug 2015 14:06:28 +0200

The point I was trying to make is a different one. Here is the issue: If
we try to optimize as much as we can then it does not make sense to put
a text string for an algorithm in there. Instead, it would make more
sense to create a registry and then number #5 would then correspond to
'AES-CMAC-256/64'.

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 28 Aug 2015 14:08:27 +0200

> sense to create a registry and then number #5 would then correspond to

Ok, no contention on that one, sorry for missing your point.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 28 Aug 2015 14:48:41 +0200

Hi Jim,

thanks for your quick response.

> You might also look at the WIP draft on github as it has a change from using maps to arrays at the top level.  This makes the code slightly different and provides a small decrease in message sizes.
Thanks for pointing this out.

> I agree with the idea of it not being useful to define the MTI algorithms.

Great. If more people in the working group agree then we might get away
without specifying algorithms that are mandatory-to-implement.

>  I am at a loss why you think it should be given that the first paragraph includes the following sentence:
> 

Ok.

> This is the name of the file in the examples project up on github (see first paragraph of appendix C).

Ok. I guess it will be removed at some point in time.

> Yes.  The string will be shortened to an integer when it gets assigned.  Until then I am using the string for the identifier.  At that point it would be something like 'a101XX'  where XX would be a…
Perfect. Maybe we could already create an assignment and use the
integers already since you are going to create a new registry for this
purpose (or are you planning to re-use an existing registry)?

> For MACs, one still needs to do some type management for the recipient to identify the key that is going to be used to compute the MAC for verification.  This is not restricted to just having a pre…
I agree that there has to be an identifier somewhere in the message to
allow the recipient to pick the right key.

The question is what is this identifier and where in the message is it.

Here I believe we will have to look at the use cases, which is what I am
doing right now.

> There is an on-again, off-again discussion about making direct key management privileged in terms of key management.  Personally, I am against this as I would prefer to see everything be uniform in all cases and I don't know that you win enough by making things special.  Part of the question is are you ever going to do anything except direct key.   From a security point of view, I would argue that you are much better off doing a KDF on a shared secret and using that on a per message basis rather than having a key that is used until some external event occurs.  
> 
Here we again need to look at the use cases we are trying to solve.
Happy to provide some input here.

In my use cases, there is another separate key management solution in
use (such as OMA LWM2M, or the stuff we are developing in ACE). The keys
+ parameters are then available to the communication parties and only
need to be applied to the CBOR payload (using COSE).

>    4:"This is the content.",

In my example I am trying to add two fields, namely a 'kid' and a
sequence number. Both values are set to '1'.

I don't understand what this line "9:[{ 3:{1:-6}}]" means.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 28 Aug 2015 15:21:02 +0200

> I don't understand what this line "9:[{ 3:{1:-6}}]" means.

In the context of

{  1:3,
   2:{1:15},

it means that this map has an entry with a key of integer 9, and a value
that is an array with a single map in it, which maps 3 to another map,
which maps 1 to -6.

The relevant translations are:

   | recipients  | 9      | For COSE_encrypt and COSE_mac              |

   | unprotected | 3      | Occurs in all structures                   |

   | alg      | 1     | int /    | COSE        | Integers are taken    |
   |          |       | tstr     | Algorithm   | from table --POINT TO |
   |          |       |          | Registry    | REGISTRY--            |

                  | direct | -6    | Direct use of CEK |

(I'm not sure about the 2:{1:15} though.)

Anyway, this is a nice demonstration why we need a better prettyprinter
(which I'm writing as we speak, by the way), as Mike pointed out.

Grüße, Carsten

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 28 Aug 2015 11:07:21 -0700

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Friday, August 28, 2015 5:49 AM
> To: Jim Schaad <[email-masked]>; [email-masked]
> >> out of curiosity I have been reading through the latest version of
> >> the COSE draft and ran into a few questions.
> >
> > You might also look at the WIP draft on github as it has a change from using
> maps to arrays at the top level.  This makes the code slightly different and
> provides a small decrease in message sizes.
> >
> >> Section 1.6 is supposed to define mandatory-to-implement algorithms
> >> but actually doesn't say what those are.
> >>
> >> such a document that will most likely be used in a variety of
> >> different environments. I would nevertheless be interested to know
> >> what the MTI algorithms should be (from your point of view).
> >
> > * Content Encryption: either AES-GCM or AES-CCM depending on if you think
> that small devices are the target market.  AES-CCM is easier to implement, but it
> prohibits any streaming encryption operation as you need to know the length of
> the output before you start.
> > * Key Management: Probably ECDH either directly or wrapped with
> > AES-KW.  The first allows for low grade origination if one does
> > static-static so it would be useful both for encryption and MACs
> > The latter three make the assumption that SHA-256 is a supported hash
> algorithm.  If that is not doable then one would need to re-look at the outputs.  I
> am not ready to jump ship to the new algorithms, but might soon be willing to
> do so with the new ECDH curve and signatures.
> >
> >>
> >> * Examples
> >>
> >> comments
> > Yes.  The string will be shortened to an integer when it gets assigned.  Until
> then I am using the string for the identifier.  At that point it would be something
> like 'a101XX'  where XX would be an encoded integer of the correct value.  This is
> expected to be done relatively soon.
> Perfect. Maybe we could already create an assignment and use the integers
> already since you are going to create a new registry for this purpose (or are you
> planning to re-use an existing registry)?

The registry is defined in section 15.5 of the document.  It is just that not all algorithms defined in the document have been assigned integer values.  Part of this is a question of which algorithms should be defined.

> > For MACs, one still needs to do some type management for the recipient to
> identify the key that is going to be used to compute the MAC for verification.
> This is not restricted to just having a pre-shared secret.  Instead one can derive
> the secret by using, for example, ECDH-SS.  Part of the question here is if
> anonymous MAC is interesting (i.e. just encrypting the MAC key for the recipient
> with RSA) or if low grade origination is needed.  Even for low-grade origination
> the direct, derived from direct and ECDH-SS direct recipient types would all give
> the needed origination proofs.
> >
> I agree that there has to be an identifier somewhere in the message to allow the
> recipient to pick the right key.
> 
> Here I believe we will have to look at the use cases, which is what I am doing
> right now.
> 
> 
> 
> >>
> >> (Note that I don't really know whether this is the encoding you
> >> envision for the header parameters.)
> >
> > There is an on-again, off-again discussion about making direct key
> management privileged in terms of key management.  Personally, I am against
> this as I would prefer to see everything be uniform in all cases and I don't know
> that you win enough by making things special.  Part of the question is are you
> ever going to do anything except direct key.   From a security point of view, I
> would argue that you are much better off doing a KDF on a shared secret and
> using that on a per message basis rather than having a key that is used until
> some external event occurs.
> >
> In my use cases, there is another separate key management solution in use (such
> as OMA LWM2M, or the stuff we are developing in ACE). The keys

I understand that this is the case.  But it still comes to the question of which key is used for a specific message if you do any KDF work or if a different key management solution is used.

Input on what the use cases really are and what the algorithms they want to use are is highly appreciated.

> 
> > I would also tend to make the same argument about making the algorithm be
> implicit rather than explicit.  While possible, I don't know that this is really a
> good idea.  I have generally found it to be a problem latter on in the process.
> However, the implementations that I have done would allow for that to happen.
> I just don't care for it as a suggested way to travel.
> >
> > This means that I would be looking more at {  1:3,
> >    2:{1:15},
> > I am not sure what you are looking at for the two parameters that you
> included in your example.  If they are just place holders then you could include
> them as well.  I omit the KID parameter from the recipient structure since that
> can be implied relatively easily if you only have one dialog going on between the
> two entities.  If you have multiple dialogs then include a KID is useful.
> 
> In my example I am trying to add two fields, namely a 'kid' and a sequence
> number. Both values are set to '1'.
> 

This line says - 
Recipients - 1   "9:["
Recipient is type direct "1:-6"
In the original example, the "4: h'6f75722d736563726574'" is a key identifier for the direct key to be used.

We still need to define a sequence number, but that is going to be dependent in part on how the key is identified/derived.  I would make it part of the KDF context process if you derive a key from the shared secret rather than being a property of the message if you use the key directly.  The other question, is the sequence number part of the COSE structure or part of the CoAP structure needs to be addressed as well.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 28 Aug 2015 11:09:47 -0700

> Sent: Friday, August 28, 2015 6:21 AM
> To: Hannes Tschofenig <[email-masked]>
> Cc: Jim Schaad <[email-masked]>; [email-masked]
> it means that this map has an entry with a key of integer 9, and a value that is an
> array with a single map in it, which maps 3 to another map, which maps 1 to -6.
> 

This is  1- algorithm and then 15 - a random integer replacement for the algorithm string.

Jim

> 
> Anyway, this is a nice demonstration why we need a better prettyprinter (which
> I'm writing as we speak, by the way), as Mike pointed out.
> 
> Grüße, Carsten

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 28 Aug 2015 12:29:35 -0700

> From: COSE [mailto:[email-masked]] On Behalf Of Ludwig Seitz
> Sent: Thursday, August 27, 2015 11:16 PM
> To: [email-masked]
..."
Got it

> cannonical encoding" i guess
Got it 

> goes for sections 5 and 6.

I would agree with this, but currently the CDDL is not a normative for the
document.  As such there is a balance that needs to be reached between what
the text says and what the CDDL is.  If CDDL were farther along in the
process, I would love to make it normative.  I like formal language in
documents because it can be automated.   As such we cannot really do this.

> This sentence is missing a word. Perhaps "... keys are used ..."?

This paragraph is gone in the next version.

> "in the worst case it because the same as doing a singature with appendix.
"

Got it

> "One unpredictable manner than can be used is to use the HKDF function

Got it

> apparent reason (or I'm just not getting it).

Editor typo.  Fixed.

Jim

---

From: Mike Jones <[email-masked]>
Date: Fri, 28 Aug 2015 21:37:48 +0000

Thanks for working on the better pretty-printer, Carsten.  As you can tell, about half of this thread wouldn't even exist if the output in the spec was sufficiently annotated. :-)

				-- Mike

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Friday, August 28, 2015 6:21 AM
To: Hannes Tschofenig <[email-masked]>
Cc: Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03

In the context of

{  1:3,
   2:{1:15},

it means that this map has an entry with a key of integer 9, and a value that is an array with a single map in it, which maps 3 to another map, which maps 1 to -6.

Anyway, this is a nice demonstration why we need a better prettyprinter (which I'm writing as we speak, by the way), as Mike pointed out.

Grüße, Carsten

_______________________________________________
COSE mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose%0a&data=01%7c01%7cMichael.Jones%40microsoft.com%7cb537c34d75e046d0c9c208d2afab8cca%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=qJeG0xvjmidQk23zNqxrueRcHK85DRB2aiiVFBL1%2b7w%3d

---

From: Göran Selander <[email-masked]>
Date: Sat, 29 Aug 2015 05:22:24 +0000

Hi Hannes, Jim,

On 2015-08-28 14:48, "Hannes Tschofenig" <[email-masked]> wrote:

>>>been
>>>Protocol 

[GS: In the ACE architecture Client and Resource Server do not necessarily
have a pre-existing security relationship to each other. For example:

- C and Authorization Server communicate securely, say, using DTLS based
on certificates; 
- RS and AS share a symmetric key K1;

But when C contacts RS for the first time, e.g. in the Push authorization
scheme, RS may never have heard of C before. E.g. C may POST to RS a COSE
object (access token) generated by AS. C can then verify the object using
K1 (or some key derived from K1) and based on the information in the
object extract or derive a key K2 (+ key identifier) for use with C.

C could then, or in the same exchange, make a request to some Resource on
RS, the request being wrapped in another COSE object (OSCOAP) protected
with K2. The algorithm used could also be different from that of the first
object. K2, key identifier and algorithm could be provided by AS to C.

So, information about key and algorithm has to come from some trusted
source, but not necessarily agreed between sender and receiver beforehand.]

>>>and the appropriate example would be something like:
>>>
>>>    {
>>>      1: 3,
>>>      2: {4: 1,6: 1},
>>management privileged in terms of key management.  Personally, I am
>>against this as I would prefer to see everything be uniform in all cases
>>and I don't know that you win enough by making things special.  Part of
>>the question is are you ever going to do anything except direct key.

[GS: In my example above, for the first object you would probably not want
to use a long term key. For the second object it may be direct key, where
the first object is used to create the direct key to use with second. But
if we would add forward secrecy w.r.t. AS, I expect we would have to
include some derivation. ]

>>  From a security point of view, I would argue that you are much better
>>off doing a KDF on a shared secret and using that on a per message basis
>>rather than having a key that is used until some external event occurs.
>> 
>> I would also tend to make the same argument about making the algorithm
>>be implicit rather than explicit.

[GS: In the example above the algorithm in the second COSE object may have
to be explicit. Alternatively information about algorithm to use with K2
may be carried in the first COSE object. ]

Göran

>>While possible, I don't know that this is really a good idea.  I have
>>generally found it to be a problem latter on in the process.  However,
>>the implementations that I have done would allow for that to happen.  I
>>just don't care for it as a suggested way to travel.
>> 
>>included in your example.  If they are just place holders then you could
>>include them as well.  I omit the KID parameter from the recipient
>>structure since that can be implied relatively easily if you only have
>>one dialog going on between the two entities.  If you have multiple
>>dialogs then include a KID is useful.
>