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

[Stephen Kent <[e-mail]>]

Jim,

How's harvest going?


> [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 ...
> [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?
> [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 ;-)
> 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.

Steve