Re: [secdir] secdir review of cose-msg-18

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Friday, September 23, 2016 10:55 AM
> To: Jim Schaad <[e-mail]>; 'secdir' <[e-mail]>; 'Justin
> Richer' <[e-mail]>; 'Kepeng Li' <[e-mail]>; 'Kathleen
> Moriarty' <[e-mail]>
> Subject: Re: secdir review of cose-msg-18
> 
> Jim,
> 
> How's harvest going?

We now have 75% of the fruit picked, and Tom says that this is the hump day for harvest this year.  From here on how we are no longer totally at the mercy of the weather and timing of doing things is more negotiable.  A lot of people are seeing high Brix numbers so am expecting to see some high alcohol wine unless the Jesus effect is put into place.  Flavors are a bit thin on the wines that have been pressed out from others in the building.  I haven't pressed anything yet.


> 
> 
> > [JLS] This was the approach that I had originally intended to take, breaking the
> document in two pieces towards the end when things were settled.  My memory
> is that this was discussed in the working group, and it was determined that one
> document was preferable to having two different documents.  I believe that this
> practice started with CMS and it was done there to deal with the question of
> how to advance to standards track for the format document and still allow the
> algorithm document to be updated.  This has not seemed to be how things have
> worked in practice, or has been necessary as protocol documents such as
> S/MIME is where the implementation requirements on algorithms are specified
> rather than in the format draft (CMS).  I therefore have less problems with the
> fact that this is one draft from that standpoint.  It would have been nicer just
> from a length prospective, but people thought that being able to reference back
> and forth in a single HTML page to be better than flipping between different
> pages.
> I hear from you and others that this is what the WG wanted. So, please add text
> at the beginning of the algs discussion noting that when it becomes necessary to
> add or remove algs the plan is to ...

My first response was this was a reasonable request and should not present any problems.  Then I tried to actually do it.  In the end the text I wrote looked a great deal like saying that one needs to follow standard IETF procedures to update a document.  Write a draft, update a registry, get it approved.  The fact that the algorithms are in this document as opposed to a separate document does not change any of the procedures about doing updates.  The only thing that it would affect is the documents status as a standard.  If the document is modified it would be reset to a lower point.  This is a reasonable discussion if and when that process step is made but should not affect things now.

I therefore would decline to make the requested change.

> > [JLS]  There was a long discussion about what to do with the CDDL grammar
> portions of the document.  Like me, it would appear that you are a strong
> advocate of doing formal languages and making them normative rather than
> making descriptive text normative.  Given the state of CDDL making it a
> normative reference would be difficult since it is still being transformed.  I have
> argued with the authors to try and get what is there published but have not been
> successful.
> I reread Section 1.3 and I see that you did say that the text describing COSE
> structures, not the CDDL, is normative. Since CDDL might change, do you feel
> that 1.3 provides enough background so that a reader need not refer the CDDL I-
> D? What's the plan if the RFC version of CDDL differs from the current version in
> a way that causes the descriptions in this document to no longer be accurate
> descriptions of COSE structures?

Two things, one we are referencing a specific version of the draft and drafts never go away so people will always be able to see what it was written to.  Additionally, I am involved in the effort to get CDDL standardized and would object to anything that is too incompatible with what is used here.  They are mostly trying to do bells and whistles which could just as easily go into a version 2 of the document.  Perfect being the enemy of the adequate.

I would also expect that if the CDDL changes too much, I would want to do a revision of the document to deal with that.


> > [JLS] I thought about making this change in the past but had an issue with the
> fact that this might make people think that the Signed Data object version could
> only be used if there were two or more signers.  It allows for one or more
> signers so it is a bit of a misnomer to say that it is a multiple signer version.  The
> structures are build in such a way that one cannot switch between the versions
> so you cannot just go from the Single Signer to the Multiple Signer when a
> second signature is added.
> >
> > I can understand the issue you are raising, but the solution has similar issues.
> The term "One or More Signer Data Object" seems to be a bit unwieldy.  Other
> suggestions would be welcome.
> Multi-signer Data Object seems concise to me ;-)

Again - I have a problem with trying to get people not to jump to the wrong conclusion for Single vs Multi.  While you do not have a problem, that does not mean that others will not see this and misconstrue the titles.

> > Section 5 describes the COSE encryption objects. I disagree with one choice of
> terminology adopted here: “recipient algorithm classes” which is described in
> 5.1.1. This is really a discussion of classes of key distribution/management
> algorithms, focusing on how each recipient of an encrypted message acquires
> the CEK used to decrypt the message. I’d prefer a less obscure name for this sub-
> section. Otherwise this section is well written and provide lots of useful details
> about how to encrypt and decrypt messages for two classes of encryption
> algorithms.
> >
> > [JLS] I agree that the term is not optimal.  There was a long discussion about
> this in the WG on the mailing list.  The original term used was "key management
> classes" (if memory serves) and there were issues raised because this is not key
> management in the world of how does a client get a symmetric or public key.
> The fact that the term was ambiguous as to the problem being solved was
> thought to be an issue.  After a long discussion the term "recipient algorithm
> classes" was adopted.
> I think "content key distribution methods" is the right title for this, having re-
> read section 13. That's what you're describing.

That is a good title, I will run that past the WG, but expect no issues with it.

Jim

> 
> Steve