Ballot for charter-ietf-cose

Yes

Benjamin Kaduk
Eric Rescorla

No Objection

Ignas Bagdonas
Deborah Brungard
Ben Campbell
Alissa Cooper
Spencer Dawkins
Suresh Krishnan
Mirja Kühlewind
Alexey Melnikov
Alvaro Retana
Adam Roach
Martin Vigoureux

  • Ballots
  • Ready for external review (00-00)
  • Approve (00-02)
  • Ready for external review (01-00)
  • Approve (01-00)

Note: This ballot was opened for revision 01-00 and is now closed.

Ballot question: "Is this charter ready for external review?"

Benjamin Kaduk Yes

Comment (2018-10-10 for -01-00)
% 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).

Eric Rescorla Yes

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Ben Campbell No Objection

Comment (2018-10-10 for -01-00)
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?

Alissa Cooper No Objection

Comment (2018-10-10 for -01-00)
s/full standard/proposed standard/

It would be helpful if the list of deliverables were to indicate the intended status of the documents.

Spencer Dawkins No Objection

Comment (2018-10-09 for -01-00)
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.

Suresh Krishnan No Objection

Comment (2018-10-10 for -01-00)
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?

Mirja Kühlewind No Objection

Alexey Melnikov No Objection

Comment (2018-10-08 for -01-00)
I think there is a typo: ANAMA --> ANIMA

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2018-10-09 for -01-00)
Minor nit: this charter uses "i.e." in a couple of places where "e.g." appears
to be intended.

Martin Vigoureux No Objection