Note: This ballot was opened for revision 01-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
% Key management and binding of keys to identities are out of scope for % the working group. The COSE WG will not innovate in terms of % cryptography. The specification of algorithms in COSE is limited to % those in RFCs or active IETF WG documents. should probably include RG documents, too. Are all the TPM-implemented algorithms in question going to meet this restriction? For the deliverable "5. Define a small set of hash functions" the text should be more clear about what constraints are placed on the design of these hash functions (the rest of the text would have me think that they are essentially for "certificate thumbprints" but that's just a guess).
I agree with Spencer that this probably needs external review. (I don't see a "can this be approved without external review" question in the ballot, so I assume that's the intent, anyway.) Otherwise, I have several mostly editorial comments: The paragraphs starting with "The SUIT working group..." seem out of place. These are motivations for work, but they occur after the discussion of work structure has already started. I propose moving them earlier in the charter. "1. Should the document be split in two? One document for the structures and one document for the algorithm definitions." The second sentence is a fragment. "The first set of three are listed in the deliverables." There are 5 in the deliverables. "A re-charter will be required to expand this list." Isn't that always true? "At the time COSE was developed, there was a sense that X.509 certificates was not a feature" s/was/were "The need to be able to identify X.509 certificates is now a feature that needs to be provided." That seems awkward. I propose "The ability to identify X.509 certificates now needs to be provided." Also, is this just a matter of identifying them, or do they need to be imbedded/included?
s/full standard/proposed standard/ It would be helpful if the list of deliverables were to indicate the intended status of the documents.
I think this is one of the recharters that is appropriate for external review before approval. Thanks for that. I see "resistant to quantum computing" a lot these days, but is this actually "resistant to attacks based on quantum-computing capabilities", or something like that? I mean, quantum computers do have other uses, I hope :-) This text "At the time COSE was developed, there was a sense that X.509 certificates was not a feature that needed to be transferred from the JOSE key document (RFC 7517). Since that time a better sense of how certificates would be used both in the IoT sphere and with COSE outside of the IoT sphere has been developed. The need to be able to identify X.509 certificates is now a feature that needs to be provided. This will additionally require definition of a small number of hash functions for compact references to certificates." alternates between "X.509 certificates" (twice) and "certificates" with no adjective (twice). If there's no difference intended, it may be useful to be consistent.
I guess the text following "The standards progression work will focus on:" needs to include "the resolution of any Errata" (currently in the 8152 case open Erratum #5066 - maybe more might turn up) as per RFC6410 Also ANAMA should be ANIMA? "The specification of algorithms in COSE is limited to those in RFCs or active IETF WG documents." Should this include IRTF RG documents as well since draft-mcgrew-hash-sigs is a CFRG document?
I think there is a typo: ANAMA --> ANIMA
Minor nit: this charter uses "i.e." in a couple of places where "e.g." appears to be intended.