Subject: [COSE] Benjamin Kaduk's Yes on charter-ietf-cose-01-00: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 10 Oct 2018 14:02:07 -0700

Benjamin Kaduk has entered the following ballot position for
charter-ietf-cose-01-00: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-cose/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

% 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).

---

From: Jim Schaad <[email-masked]>
Date: Wed, 10 Oct 2018 20:12:13 -0700

> -----Original Message-----
> From: COSE <[email-masked]> On Behalf Of Benjamin Kaduk
> Sent: Wednesday, October 10, 2018 2:02 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: [COSE] Benjamin Kaduk's Yes on charter-ietf-cose-01-00: (with
> COMMENT)
> 
email
> addresses included in the To and CC lines. (Feel free to cut this
introductory
> paragraph, however.)
> % 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.

I don't know if the FIDO algorithms are going to meet this bar.  I do know
that there is going to need to be some serious review on these algorithms by
CFRG along with others to get this to progress very far.  I would not be
surprised if it did not end up as an RFC rather than just the current FIDO
document as I find the current FIDO document difficult to read.  

I put this restriction in to avoid vanity algorithms from popping up but did
not think hard enough about the FIDO algorithms.

The specification of algorithm in COSE I limited to those published as RFCs,
are active IETF WG documents or have had significant review by CFRG.

> 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).

"small set" = 3.  

There is a reference both in the SUIT paragraph and in this paragraph about
needing to define hash algorithms.  This could be combined into a single
paragraph if desired.

Jim

> 
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 Oct 2018 16:22:30 -0500

> are active IETF WG documents or have had significant review by CFRG.

That works, thanks.

> needing to define hash algorithms.  This could be combined into a single

I was just trying to point out that this deliverable is basically saying
"there should exist some hash functions", without stating or referring to
any text that says "these hash functions are for compact references to
certificates".  But it's not like this was a blocking comment, so, as
Spencer says, "do the right thing".

-Benjamin