CBOR Object Signing and Encryption
charter-ietf-cose-03

[Ballot comment]
Not familiar with COSE, but, is "attributes for COSE" a well-understood terminology ?

If not mistaken, "i.e." must be followed by a comma (but, hey, English is not my native language, so, can be wrong).

In "The WG currently has two deliverables", suggest replace "deliverables" by "work items".

The amount of descriptions/restrictions for the CBOR encoding for a certificate compared to nearly no descriptions/restrictions for the other "deliverable" is really surprising. Is there a COSE WG consensus on this second deliverable ?

Suggest to move the § starting with "The working group will coordinate its progress " at the end of the charter as it is often the case.

[Ballot comment]
Paragraph 9, comment:
> 2. A CBOR encoding of the certificate profile defined in RFC 5280.
> It is expected that the encoding works with RFC 7925 and takes into
> consideration any updates in draft-ietf-uta-tls13-iot-profile-00.  The
> encoding may also include other important IoT certificate profiles like IEEE
> 802.1AR.
> The main objective is to define a method of encoding current X.509
> certificates that meet a specific profile into a smaller format. This encoding
> is invertible so they can be expanded and normal X.509 certificate processing
> used.  The data structures used for such encoding of X.509 certificates are
> expected to produce a compact encoding for certificate information, and are
> not necessarily tied specifically to X.509 certificates.  Accordingly, a
> secondary objective is to reuse these data structures to produce a natively
> signed CBOR certificate encoding; such a structure is relevant in situations
> where DER parsing and the machinery to convert between CBOR and DER encodings
> are unnecessary overhead, such as embedded implementations.  The possibility
> of a joint certificate artifact, conveyed in CBOR encoding but including
> signatures over both the CBOR and DER encodings, may be explored.  CBOR
> encoding of other X.509 certificate related data structures may also be
> specified to support relevant functions such as revocation: Certificate
> Revocation List (RFC 5280) or OSCP Request/Response (RFC 6960); or certificate
> enrolment: Certificate Signing Request (RFC 2986).  This work will be based on
> draft-mattsson-cose-cbor-cert-compress.  The working group will collaborate
> and coordinate with other IETF WGs such as TLS, UTA, LAKE to understand and
> validate the requirements and solution.

This seems very detailed for a charter. Also, basing chartered work on
(individual) I-Ds might run into issues.

-------------------------------------------------------------------------------
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Paragraph 1, nit:
- within the IETF (i.e. ACE, CORE, ANIMA, 6TiSCH and SUIT) as well as
                                                            ^^^^^^^^^
- outside of the IETF (i.e. W3C and FIDO). There are a number of
        ---
+ within the IETF (i.e., ACE, CORE, ANIMA, 6TiSCH and SUIT) and
                      +                                    ^^
+ outside the IETF (i.e., W3C and FIDO). There are a number of
                        +

Paragraph 3, nit:
- which would fit the criteria of being IETF consensus algorithms.
  ^ ^^^
- Potential candidates would include those algorithms which have been evaluated by
                                                      ^ ^^^
+ that would fit the criteria of being IETF consensus algorithms.
  ^ ^^
+ Potential candidates would include those algorithms that have been evaluated by
                                                      ^ ^^

Paragraph 4, nit:
- Potential candidate would not include national standards based algorithms
                                                ^        ^
- which have not gone through a similar public review process.
  ^ ^^^
+ Potential candidates would not include national-standards-based algorithms
                    +                          ^        ^
+ that have not gone through a similar public review process.
  ^ ^^

Paragraph 5, nit:
- attributes which are not in charter but are of general public interest.
            ^ ^^^          ^
+ attributes that are not in-charter but are of general public interest.
            ^ ^^          ^

Paragraph 6, nit:
- CORE working groups to ensure that we are fulfilling the needs of
                                    ^^ ^^^
+ CORE working groups to ensure that it is fulfilling the needs of
                                    ^^ ^^

Paragraph 9, nit:
- is invertible so they can be expanded and normal X.509 certificate processing
+ is invertible, so they can be expanded and normal X.509 certificate processing be
              +                                                                +++

Paragraph 9, nit:
- enrolment: Certificate Signing Request (RFC 2986).  This work will be based on
+ enrollment: Certificate Signing Request (RFC 2986).  This work will be based on
      +

[Ballot block]
I don't think we can approve this on the 2018-10-25 telechat, since the external review feedback period ends on 2018-10-25 (so there might reasonably community feedback still pending).

[Ballot comment]
I had some mostly editorial comments at https://mailarchive.ietf.org/arch/msg/cose/9eTTcLBTTl4gU9U0jmdCptZuuGQ that do not seem to have been addressed. None of them were show stoppers, so if they were _intentionally_ not addressed, that is fine :-)

[Ballot block]
It doesn't look like this has been revised since it was sent for external review yet, has it? I noticed that Suresh's question about IRTF documents and about "ANAMA" hasn't resulted in either replies or text changes.

I'm sure this will be a very short-lived BLOCK, which are the best kind of BLOCK ...

[Ballot comment]
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?

[Ballot comment]
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?

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

[Ballot comment]
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.

[Ballot comment]
I was initially sceptical that there were enough folks
interested in CBOR to justify this but was convinced
that there are.

That does sort-of create a precedent for us that anytime
someone comes along with a way of representing data
on the wire then we should be ok with a WG to define
the crypto for that so long as there's enough folks
interested. I'm fine with that, but that does follow from
saying yes here I think so I just wanted to call that
out to the IESG in case someone disagrees.

[Ballot comment]
Phill is not wrong in his comments, and I have some sympathy for the path he would rather go down.

That said, there is clearly interest and need here, and the energy to do the work, and that would be so regardless of how we got here -- indeed, even if CBOR had just been an ad hoc representation format that people had started to use, that came completely from outside the IETF.

I think, therefore, that this working group should go ahead... and that the sort of thing that Phill suggests should also go ahead, if there is interest and energy to start a working group on it.

[Ballot comment]
Since this is the first charter I am putting through, I didn't realize I also had to add a ballot after putting this in external review.  If I need to defer this to the next call, that will have to be ok...  The working group is active on items anyway, so it shouldn't hold them up much.

Since this is the first charter I am putting through, I didn't realize I also had to add a ballot after putting this in external review.  If I need to defer this to the next call, that will have to be ok...  The working group is active on items anyway, so it shouldn't hold them up much.

[Ballot comment]
Maybe I am missing something, but I don't see an explicit statement of what COSE is setting out to accomplish until I get to the deliverables. I can infer it from the group name, and from the JOSE reference. But a sentence in the first paragraph to the effect that COSE seeks to create CBOR-based object signing and encryption formats would be helpful. (Probably right before the JOSE reference).

[Ballot comment]
Thanks for addressing my comments. Just preserving a
part of that below as it may be of use to other ADs in
their evaluations.

I was initially skeptical of this work, doubting that
there is really sufficient real interest in CBOR to
justify spending the time on a WG. However, (just about)
enough people argued that they would or are using CBOR to
convince me that there could well be a real constituency
here. And given that, I'd prefer the work be done in the
IETF rather than ad-hoc and possibly by some folks who'd
prioritise constrained-system requirements too much over
security and privacy requirements. So in the end, I'm for
doing this.

[Ballot block]
I was initially skeptical of this work, doubting that
there is really sufficient real interest in CBOR to
justify spending the time on a WG. However, (just about)
enough people argued that they would or are using CBOR to
convince me that there could well be a real constituency
here. And given that, I'd prefer the work be done in the
IETF rather than ad-hoc and possibly by some folks who'd
prioritise constrained-system requirements too much over
security and privacy requirements. So in the end, I'm for
doing this.

I do have one blocking thing to discuss though, but that
should be easy enough as we mentioned it on the list
already and I think folks are ok with the sentiment and
we'll just need to get the right words. Anyway, my
blocking point is:

I think you need to add something to the effect that this
WG will not invent any new cryptography. (It is likely to
be asked to, since smaller-footprint is a requirement
that leads towards that.) I'd suggest adding "The COSE WG
will not innovate in terms of cryptography.  Any
algorithms to be used in COSE that are not already
well-established for use as part of some IETF standards
track specification will need to be checked via the CFRG
before being adopted here." I'm fine with other wordings,
what I wanted the above to allow was a bit more that just
what is already MTI in standards track RFCs, but to not
allow every single algorithm that has even gotten an IANA
code point somewhere to be just adopted as MTI by COSE.
And of course, for anything that is actually new to have to
go via CFRG first.

After we resolve this, I'll be balloting YES.

[Ballot comment]

- I think you could (and maybe should) lose all the
references to JOSE - this work involves re-doing all of
the same things, and won't be interoperable so I don't
see any value in re-use of registries to be honest. (And
maybe there is potential for minor confusion/harm there.)
I read the current text with all it's JOSE references as
trying to justify that the work is not just more JOSE
(both involve a lot of the same people), but at the same
time saying "this is like JOSE." And I don't think that
is needed - if there is real use of CBOR, then there will
be a real use of COSE. That doesn't depend on JOSE at
all, but more on whether folks see CBOR as being better
than JSON. The crypto primitives will just follow from
the application developer's chosen form of structured
encoding.

- The text assumes that ACE, DICE and CORE are already
bought into CBOR. I don't believe that is necessarily the
case, though I'd not be surprised if a bunch of folks
would argue for it to be the case.

- The milestone dates are nonsense. I'll buy the chairs a
beverage if they happen though. It is fine if folks want
to believe those dates though.