Subject: [Cose] FW: New Version Notification for draft-schaad-cose-02.txt

From: "Jim Schaad" <[email-masked]>
Date: Fri, 5 Jun 2015 17:37:57 -0700

Since we now have an official working group.  I will propose this as a candidate draft to address the specification milestone.

I am willing to add the algorithms piece to this document if that is the desire of the group, or it can be done as an independent document (my initial preference).

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, June 05, 2015 5:22 PM
> To: Jim Schaad; Jim Schaad
> Subject: New Version Notification for draft-schaad-cose-02.txt
> 
> 
> A new version of I-D, draft-schaad-cose-02.txt has been successfully submitted
> by Jim Schaad and posted to the IETF repository.
> 
> Name:		draft-schaad-cose
> Revision:	02
> Title:		CBOR Encoded Message Syntax
> Document date:	2015-06-05
> Group:		Individual Submission
> Pages:		35
> URL:            https://www.ietf.org/internet-drafts/draft-schaad-cose-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-schaad-cose/
> Htmlized:       https://tools.ietf.org/html/draft-schaad-cose-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-schaad-cose-02
> 
> 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 how to do signatures, message
>    authentication codes and encryption using this data format.  The work
>    in this document is derived in part from the JSON web security
>    documents using the same parameters and algorithm identifiers as they
>    do.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat

---

From: "Kepeng Li" <[email-masked]>
Date: Sat, 06 Jun 2015 09:48:34 +0800

Hi Jim,

Thanks for the draft.

>I am willing to add the algorithms piece to this document if that is the
>desire of the group, or it can be done as an independent document (my
>initial preference).edx

According to our milestones, the algorithm piece is a separate item.

Jun 2015 - Submit COSE specification as a WG item
  Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG item

Kind Regards
Kepeng

在 6/6/15 8:37 am， "Jim Schaad" <[email-masked]> 写入:

>Since we now have an official working group.  I will propose this as a
>candidate draft to address the specification milestone.
>
>I am willing to add the algorithms piece to this document if that is the
>desire of the group, or it can be done as an independent document (my
>initial preference).
>
>Jim
> 
>
>> URL:            
>>https://www.ietf.org/internet-drafts/draft-schaad-cose-02.txt
>_______________________________________________
>Cose mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cose

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 5 Jun 2015 19:31:00 -0700

> From: Cose [mailto:[email-masked]] On Behalf Of Kepeng Li
> Sent: Friday, June 05, 2015 6:49 PM
> To: Jim Schaad; [email-masked]
> Subject: Re: [Cose] FW: New Version Notification for draft-schaad-cose-02.
txt
>
> Hi Jim,
>
> Thanks for the draft.
>
> >I am willing to add the algorithms piece to this document if that is
> >the desire of the group, or it can be done as an independent document
> >(my initial preference).edx
>
>

That just says that we need a document to cover that milestone.  It can be a
single document or a combined document as the working group feels best.

Jim

> >I am willing to add the algorithms piece to this document if that is
> >the desire of the group, or it can be done as an independent document
> >(my initial preference).
> >
> >Jim
> >
> >
> >> A new version of I-D, draft-schaad-cose-02.txt has been successfully
> >>submitted  by Jim Schaad and posted to the IETF repository.
> >>
> >> Name:		draft-schaad-cose
> >> Revision:	02
> >> 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.
> >>
> >> The IETF Secretariat
> >

---

From: Mike Jones <[email-masked]>
Date: Sat, 6 Jun 2015 03:04:47 +0000

For what it's worth, I'd advocate having a separate algorithm document for the same reasons that JOSE did.  For one, it enables that document to be revised in the future without having to then revise the underlying signature/MAC/encryption/key representations.

Also, based on my experience as a JOSE editor, I think the result was cleaner because we separated the algorithm descriptions from the descriptions of how to perform cryptographic operations.  It was good discipline to have to describe the steps to create and use the data structures without falling back on particulars of specific algorithms.

Also, the single-purpose nature of an algorithms doc can make it easier to read and use a reference.  You're not having to sort out what are data descriptions and what are algorithm descriptions.  It's just algorithms.

				Cheers,
				-- Mike

P.S.  I agree with Jim's procedural point that the charter allows the working group to produce deliverables either in combined or separated documents.

-----Original Message-----
From: Cose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Friday, June 05, 2015 7:31 PM
To: 'Kepeng Li'; [email-masked]
Subject: Re: [Cose] FW: New Version Notification for draft-schaad-cose-02.txt

txt
> According to our milestones, the algorithm piece is a separate item.

That just says that we need a document to cover that milestone.  It can be a single document or a combined document as the working group feels best.

Jim

> >Since we now have an official working group.  I will propose this as 
> >a candidate draft to address the specification milestone.
> >
> >> A new version of I-D, draft-schaad-cose-02.txt has been 
> >>successfully submitted  by Jim Schaad and posted to the IETF repository.
> >>
> >> Name:		draft-schaad-cose
> >> Revision:	02

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 6 Jun 2015 10:39:31 +0300

> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-schaad-cose-02

Did a quick review (some of the stuff is new, some is still standing
from previous review (I did go through the reply briefly):

1) Section 5:

"  recipients  contains the recipient information.  The field can have
      one of two data types:

   o  An array of COSE_encrypt elements, one for each recipient.
"

Err... Expected list of 2 items, found 1.

2) Section 5.1.2:

"The 'protected', 'iv', 'aad', 'ciphertext' and 'recipients' fields
MUST be absent."

Apeendix B contains some text about applying RSA-KEM. It says
there are three layers. Wouldn't the middle layer be key wrapping,
and thus seemingly violate that MUST not have recipients?

3) Sections 5.1.3, 5.1.4 and 5.1.5:

"The 'protected', 'aad', and 'iv' fields MUST be absent."

Recipients is allowed? What semantics does that have?
Decrypts to private key of appropriate type, to be used
for decryption?

4) Section 5.1.4:

"The 'protected', 'aad', and 'iv' fields MUST be absent."

Can ciphertext field be present, depending on the algorithm?
Epk has to be present, wouldn't that contain the key agreement
values?

5) Section 5.1.5:

"At a minimum, the 'unprotected' field SHOULD contain the 'alg'
parameter, a parameter identifying the recipient asymmetric key,
and a parameter with the sender's asymmetric public key."

I realize this is written to allow ECDH static-static. However,
as comment of adding ECDH static-static, if one does that, one
either has to either:

- Include a nonce field, to be mixed in at KDF stage.
- Be careful what key wrapping algorithms one uses.

The reason for that is that many encryption algorithms have
nonces that are:

- Too short to randomly generate without unacceptably high risk
  of collision (and used too long to reliably count).
- Catastrophically break the algorithm if repeated.

e.g. AES-KW is ok, since it lacks nonce entierely. e.g. AES-GCM is not,
because its 12 byte nonce is too short for random generation.

6) Section 5.2:

"If there is protected data, CBOR encode the map to a byte string
and place in the protected field of the Enc_structure and the
COSE_Encrypt structure."

And what if there isn't, what is written into Enc_structure?
- Nonexistent?
- 0xF6 (null)?
- 0x60 (empty string)?
- 0x61 0xA0 (empty map)?

7) Section 5.2:

"Copy the 'aad' field from the COSE_Encrypt structure to the
Enc_Structure."

And what if 'aad' is absent, what is copied?
- Nonexistent (creates problems if protected also can be nonexistent)?
- 0xF6 (null)?
- 0x60 (empty string, but to me it seems nonexistent != empty string)?

8) Section 6:

"Create a MAC_structure and copy the protected and payload
elements from the COSE_mac structure."

What if protected element is missing (the choices seem to be the same
as in 6)? 

9) Section C:

It might be possible to format those examples in way that is easier to
read (TODO: Try various formattings).

10) Section C.1:

Maybe add TODO note about ECDH-SS. Does not seem to be defined
anywhere (I searched this draft, JWA, JWK, JWE and JWS).

[TODO: ECDH-SS and spk parameter are to be defined]

Or something like that.

11) Section D:

It occurs to me that if using "decode to pointer table", the technique
is more efficient the smaller the largest understood key is (or the
less understood keys there are).

OTOH, dunno to what extent overlaps in the table complicate
implementations. Encryption, Signatures and MACs seem quite separate.

The idea of "decode to pointer table" is to first do scan pass where
pointers to values of various fields are written into table, and then
operate on those pointers, decoding appropriate values (this is since
values can appear in any order in maps).

12) (general, algorithms draft stuff):

How would ECDH using CFRG curves (that should be stable now) be done?
The public keys have only one 32/56 byte octet string (and the private
keys too).

While ECDH part should be stable, that is part of larger document, where
at least signature parts are under work, so I don't know about the
schedule of that draft.

-Ilari