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 protected]> wrote: >Please look at this and see if you think it covers the required changes. > >https://github.com/cose-wg/cose-spec/pull/150 > >jim > > >> -----Original Message----- >> From: COSE [mailto:[email protected]] On Behalf Of Göran Selander >> Sent: Thursday, May 19, 2016 6:52 AM >> To: Jim Schaad <[email protected]> >> Cc: [email protected]; [email protected] >> 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. >> >> 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 protected] >> on behalf of [email protected]> wrote: >> >> >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 protected]] On Behalf Of internet- >> >> [email protected] >> >> Sent: Thursday, May 12, 2016 5:20 PM >> >> To: [email protected] >> >> Cc: [email protected] >> >> 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. >> >> >> >> 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/ >> >> >> >> _______________________________________________ >> >> COSE mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/cose >> > >> >_______________________________________________ >> >COSE mailing list >> >[email protected] >> >https://www.ietf.org/mailman/listinfo/cose >> >> _______________________________________________ >> COSE mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/cose > _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
