Subject: [COSE] I-D Action: draft-ietf-cose-msg-12.txt

From: [email-masked]
Date: Thu, 12 May 2016 17:19:47 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the CBOR Object Signing and Encryption of the IETF.

        Title           : CBOR Encoded Message Syntax
        Author          : Jim Schaad
	Filename        : draft-ietf-cose-msg-12.txt
	Pages           : 112
	Date            : 2016-05-12

Abstract:
   Concise Binary Object Representation (CBOR) is data format designed
   for small code size and small message size.  There is a need for the
   ability to have the basic security services defined for this data
   format.  This document specifies processing for signatures, message
   authentication codes, and encryption using CBOR.  This document also
   specifies a representation for cryptographic keys using CBOR.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-cose-msg/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-cose-msg-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-12

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 12 May 2016 17:41:41 -0700

I believe that this draft represents all of the decisions that were taken at
BA.  I have been through the draft a couple of times to look for problems
and I believe that it is now ready for a working group last call.

Jim

> -----Original Message-----
> From: COSE [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: Thursday, May 12, 2016 5:20 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [COSE] I-D Action: draft-ietf-cose-msg-12.txt
> 
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Justin Richer <[email-masked]>
Date: Fri, 13 May 2016 17:46:19 -0500

Thanks, Jim.

Everyone, please look over the current draft as well as the issues list (most of which have been marked “Complete”, or otherwise refer to separate documents). 

https://github.com/cose-wg/cose-issues/issues <https://github.com/cose-wg/cose-issues/issues>

We’ll give people two weeks starting today to look things over and bring up any showstoppers, then we’ll start the WGLC in earnest.

 — Justin, your COSE chair

> On May 12, 2016, at 7:41 PM, Jim Schaad <[email-masked]> wrote:
>

---

From: Göran Selander <[email-masked]>
Date: Thu, 19 May 2016 13:51:42 +0000

Hi Jim

A couple of questions related to applying COSE rather than issues with the
draft itself. 

1. As you know we are looking at building security protocols using COSE.
For EDHOC we need to support X.509 certificate based authentication of the
DH exchange. With PSK and RPK, which is currently described, EDHOC is an
exchange of COSE messages. What would be a natural way to include a public
key certificate in a COSE_Sign1 object, the public key of the certificate
intended to be used by the recipient to verify the signature of the COSE
object? 

2. Another thing we discussed previously was the detailed specification
for deriving the shared secret with ECDH, analogously to section 7.3.3 of
https://tools.ietf.org/html/draft-ietf-tls-tls13-12

I note in section 12.4.1

" The mathematics for Elliptic Curve Diffie-Hellman can be found in
   [RFC6090].  In this document the algorithm is extended to be used
   with the two curves defined in [RFC7748].

   ECDH is parameterized by the following:

   o  Curve Type/Curve: The curve selected controls not only the size of
      the shared secret, but the mathematics for computing the shared
      secret. “

There are at least two kinds of shared secret, one is a point on a curve,
denoted g^(j*k) in RFC6090, or alternatively a coordinate. Another is the
byte string derived from g^(j*k) or its coordinate, used for subsequent
key derivation.  The former is defined with the curve, but not necessarily
the latter.

For example in the case of RFC7748, section 6.1, "Alice and Bob can then
use a key-derivation
   function that includes K, K_A, and K_B to derive a symmetric key.”

Section 11 in draft-ietf-cose-msg nicely describes the key derivation
given the shared secret, but I can’t find the reference to the exact
procedure for obtaining the shared secret starting from this draft.

Not insisting on it be included in this draft. For now I just want a
confirmation that I haven’t missed something.

Göran

On 2016-05-13 02:41, "COSE on behalf of Jim Schaad" <[email-masked]
on behalf of [email-masked]> wrote:

>> This draft is a work item of the CBOR Object Signing and Encryption of
>>the
>IETF.
>>

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 21 May 2016 10:35:04 -0700

> From: COSE [mailto:[email-masked]] On Behalf Of Göran Selander
> Sent: Thursday, May 19, 2016 6:52 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [COSE] FW: I-D Action: draft-ietf-cose-msg-12.txt
> 
> Hi Jim
> 
> A couple of questions related to applying COSE rather than issues with the draft
> itself.
> 
> For EDHOC we need to support X.509 certificate based authentication of the DH
> exchange. With PSK and RPK, which is currently described, EDHOC is an
> key certificate in a COSE_Sign1 object, the public key of the certificate intended
> to be used by the recipient to verify the signature of the COSE object?
> 

We do not have a current method of carrying certificates in a COSE message at this time.  When we were discussing things, it was presumed and confirmed that while certificates may be used, they were going to be pre-provisioned in some manner.  The additional overhead associated with carrying certificates was not considered to be part of the target environment.

That said, for pre-provisioned certificates one would place the SPKI field into the KID field of a message. 

If one really wants to carry certificates, then one would need to define a new header field that allowed for one or more certificates to be carried as part of the message.  One might also wish to provide for OCSP responses to be carried as well for long term messages and good time capabilities in order to ease revocation checking.  I do recognize that many of the situations you are looking at would probably not do revocation checking but it might be reasonable to allow for the ability in the future.

> 
> 2. Another thing we discussed previously was the detailed specification for
> deriving the shared secret with ECDH, analogously to section 7.3.3 of
> There are at least two kinds of shared secret, one is a point on a curve, denoted
> g^(j*k) in RFC6090, or alternatively a coordinate. Another is the byte string
> derived from g^(j*k) or its coordinate, used for subsequent key derivation.  The
> former is defined with the curve, but not necessarily the latter.
> 
> For example in the case of RFC7748, section 6.1, "Alice and Bob can then use a
> key-derivation
> Section 11 in draft-ietf-cose-msg nicely describes the key derivation given the
> shared secret, but I can’t find the reference to the exact procedure for obtaining
> the shared secret starting from this draft.
> 
> Not insisting on it be included in this draft. For now I just want a confirmation
> that I haven’t missed something.

I remember that you told me about this and I did intend to deal with the first case, but I forgot to write it down and missed it.  

I thought that I had dealt with the second case, but I cannot seem to find the text at the moment so it might have been lost.  I will look for it and see if I am just missing it or if the text got lost and needs to be re-added.

Jim

> >I believe that this draft represents all of the decisions that were
> >taken at BA.  I have been through the draft a couple of times to look
> >for problems and I believe that it is now ready for a working group
> >last call.
> >
> >Jim
> >
> >
> >> This draft is a work item of the CBOR Object Signing and Encryption
> >>of the
> >IETF.
> >>

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 23 May 2016 21:28:21 -0700

Please look at this and see if you think it covers the required changes.

https://github.com/cose-wg/cose-spec/pull/150

jim

---

From: Göran Selander <[email-masked]>
Date: Fri, 27 May 2016 13:55:08 +0000

Thanks, I think it covers the points discussed. Just some minor points for
consideration:

"Shared Secret to Byte String:”

I understand this, but may be confusing since the term “shared secret” is
used elsewhere in the document for what here is called "Byte String”. I
don’t have a good proposal for terminology though.

"run through the I2OSP function defined in <xref target="RFC3447"/> using
the same computation for n as is defined in <xref target="ECDSA"/>.”

It is not obvious what  “computation for n” that is being referred.

Göran

On 2016-05-24 06:28, "Jim Schaad" <[email-masked]> wrote:

>>for
>>given the

---

From: Mike Jones <[email-masked]>
Date: Fri, 27 May 2016 16:45:52 +0000

Justin,

You wrote on the 13th that we had two weeks to review these issues and I scheduled time today to review them but I got up this morning and discovered that you’d already closed the issues before the two weeks was up (which would be at 3:46 Pacific time this afternoon).  I hope therefore that if I want to make comments on any of the closed issues today as a result of my reviews that you’ll reopen them so I can do so.

                                                       Thank you,
                                                       -- Mike

From: COSE [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Friday, May 13, 2016 3:46 PM
To: Jim Schaad <[email-masked]>
Cc: cose <[email-masked]>
Subject: Re: [COSE] I-D Action: draft-ietf-cose-msg-12.txt

Thanks, Jim.

https://github.com/cose-wg/cose-issues/issues

On May 12, 2016, at 7:41 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:

Jim

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of internet-
[email-masked]<mailto:[email-masked]>
Sent: Thursday, May 12, 2016 5:20 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [COSE] I-D Action: draft-ietf-cose-msg-12.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

This draft is a work item of the CBOR Object Signing and Encryption of the
IETF.

Abstract:

Please note that it may take a couple of minutes from the time of
submission

until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

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

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 27 May 2016 13:34:04 -0700

> Sent: Friday, May 27, 2016 6:55 AM
> I understand this, but may be confusing since the term “shared secret” is used
> elsewhere in the document for what here is called "Byte String”. I don’t have a
> good proposal for terminology though.

Yeah, I am still trying to come up with something better.

> 
> 
> "run through the I2OSP function defined in <xref target="RFC3447"/> using the
> same computation for n as is defined in <xref target="ECDSA"/>.”
> 

Does this mean that you did not figure out that it was a reference to a section in the document (section 8.1) or that you did not understand how n was computed in that section?

Jim

> >> A couple of questions related to applying COSE rather than issues
> >>with the draft  itself.
> >>
> >> For EDHOC we need to support X.509 certificate based authentication
> >>of the DH  exchange. With PSK and RPK, which is currently described,
> >>EDHOC is an  exchange of COSE messages. What would be a natural way to
> >>include a public  key certificate in a COSE_Sign1 object, the public
> >>key of the certificate intended  to be used by the recipient to verify
> >>the signature of the COSE object?
> >>
> >>
> >> 2. Another thing we discussed previously was the detailed
> >>specification for  deriving the shared secret with ECDH, analogously
> >>to section 7.3.3 of
> >> g^(j*k) in RFC6090, or alternatively a coordinate. Another is the
> >>byte string  derived from g^(j*k) or its coordinate, used for
> >>subsequent key derivation.  The  former is defined with the curve, but
> >>not necessarily the latter.
> >>
> >> For example in the case of RFC7748, section 6.1, "Alice and Bob can
> >>then use a  key-derivation
> >> >taken at BA.  I have been through the draft a couple of times to
> >> >look for problems and I believe that it is now ready for a working
> >> >group last call.
> >> >
> >> >Jim
> >> >
> >> >
> >> >>    for small code size and small message size.  There is a need
> >> >> for
> >>the

---

From: Justin Richer <[email-masked]>
Date: Sat, 28 May 2016 20:11:41 -0400

Mike,

I think it's a little ridiculous to expect a fully two-week window to be 
open to the exact minute from which it was specified in email, a medium 
which is prone to delays and delivery oddities at the best of times. The 
review period was in fact two weeks long and was closed on the calendar 
day specified. I'm sorry that this confused you. Maybe I'll start saying 
"fortnight" instead so that people realize the implied loose 
granularity? Regardless, in case anyone else is still confused: the WGLC 
will close sometime on June 10. You've got almost two weeks, people, 
don't put off your reviews until the last second.

As for the present: Whatever issues you may have discovered during your 
review on the last day can still be brought up. WGLC isn't the *end* of 
comments, it's a period *for* comments. You can comment on closed issues 
without my reopening anything, and thus I will not be reopening any 
issues. However, as the document is currently in WGLC, I would prefer if 
you bring the review to the list as requested in the WGLC email.

If you've got something to say about COSE then now is a really, really 
good time to say it.

Thank you,

  -- Justin, your COSE chair

On 5/27/2016 12:45 PM, Mike Jones wrote:
>
> Justin,
>
> You wrote on the 13^th that we had two weeks to review these issues 
> and I scheduled time today to review them but I got up this morning 
> and discovered that you’d already closed the issues before the two 
> weeks was up (which would be at 3:46 Pacific time this afternoon).  I 
> hope therefore that if I want to make comments on any of the closed 
> issues today as a result of my reviews that you’ll reopen them so I 
> can do so.
>
> Thank you,
>
> -- Mike
>
> *From:*COSE [mailto:[email-masked]] *On Behalf Of *Justin Richer
> *Sent:* Friday, May 13, 2016 3:46 PM
> *To:* Jim Schaad <[email-masked]>
> *Cc:* cose <[email-masked]>
> *Subject:* Re: [COSE] I-D Action: draft-ietf-cose-msg-12.txt
>
> Thanks, Jim.
>
> Everyone, please look over the current draft as well as the issues 
> list (most of which have been marked “Complete”, or otherwise refer to 
> separate documents).
>
> We’ll give people two weeks starting today to look things over and 
> bring up any showstoppers, then we’ll start the WGLC in earnest.
>
>         [email-masked] <mailto:[email-masked]>
>         To: [email-masked] <mailto:[email-masked]>
>         Cc: [email-masked] <mailto:[email-masked]>
>         for the
>         until the htmlized version and diff are available at
>         tools.ietf.org <http://tools.ietf.org>.
>
>         [email-masked] <mailto:[email-masked]>