Subject: [COSE] Recharter the COSE working group.

From: Jim Schaad <[email-masked]>
Date: Sat, 11 Aug 2018 14:03:43 -0700

I have approached the Security ADs about progressing the COSE from Proposed
Standard to Full Standard.  They have indicated that they would be open to
this.  In addition to this, there are a couple of other documents related to
COSE which are looking for homes and this would provide an opportunity for
them to be dealt with as well.

The charter text that I have proposed is:

*********************************

CBOR Object Signing and Encryption (COSE, RFC 8152) describes how to create
and process signatures, message authentication codes, and encryption use
Concise Binary Object Representation (CBOR, RFC 7049) for serialization.
COSE additionally describes a representation for cryptographic keys.

COSE has been picked up and is being used both by a number of groups within
the IETF (i.e. ACE, CORE, ANAMA, 6TiSCH and SUIT) as well as outside of the
IETF (i.e. W3C and FIDO).  There are a number of implementations, both open
source and private,  now in existence.  The specification is now
sufficiently mature that it makes sense to try and advance it to STD status.

The standards progression work will focus on:
1. Should the document be split in two?  One document for the structures and
one document for the algorithm definitions.
2.  What areas in the document need clarification before the document can be
progressed?
3.  What implementations exist and do they cover all of the major sections
of the document?

There are a small number of COSE related documents that will also be
addressed by the working group dealing with additional attributes and
algorithms that need to be reviewed and published.  The first set of three
are listed in the deliverables.  A re-charter will be required to expand
this list.

The SUIT working group has identified a need for the use of hash base
signatures in the form of Leighton-Micali Signatures (LMS)
(draft-mcgrew-hash-sigs).  This signature form is resistant to quantum
computing and is low-cost for validation.

The W3C Web Authentication working group has identified a need for the
ability to use algorithms which are currently part of TPMs which are widely
deployed.  Many of the algorithms for this work are not expected to be IETF
recommended algorithms.

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.

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.

The working group will coordinate its progress with the ACE, SUIT and CORE
working groups to ensure that we are fulfilling the needs of these
constituencies to the extent relevant to their work. 
Other groups may be added to this list as the set of use cases is expanded.

The WG will have four deliverables:

1. Republishing a version of RFC 8152 suitable for advancement to full
standard.
2. Use of Hash-based Signature algorithms in COSE using
draft-housley-suit-cose-hash-sig as a starting point.
3. Placement of X.509 certificates in COSE messages and keys using
draft-schaad-cose-x509 as a starting point.
4. Define the algorithms needed for W3C Web Authentication for COSE using
draft-jones-webauthn-cose-algorithms and draft-jones-webauthn-secp256k1 as a
starting point.

******************************

I don't currently have a set of milestones associated with this charter in
part because I have not talked to everybody about what they believe they can
do.

For RFC 8152, assuming that the document is split into two pieces, I would
expect that we should be able to get the split documents to the IESG prior
to the Prague meeting.  Assuming that the IESG requires that we wait an
additional six months of the new document I would expect that roughly nine
months later an updated document could go to the IESG for full standard.

The hash-based signature algorithm document is probably in good shape, the
big question would be should it be coordinated with the similar documents in
the LAMPS working group.  If that is not needed then this should take less
than a year to finish.

The X.509 certificates draft needs to get review, but I believe that it is
good shape now and probably ready to go.

I don't know what the state is for the two Web Authentication drafts as I
have not read the first in a while and have never read the second. 

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 12 Aug 2018 23:47:11 +0200

Hi Jim,

Interesting initiative.

> deployed.  Many of the algorithms for this work are not expected to be IETF

I also think it would be good to create a code space for hash algorithms for use with COSE.

We need this for SUIT.

Also, today this weird little thing surfaced:
https://tools.ietf.org/html/draft-multiformats-multihash-00
(Yet another registry for hash functions…  I’ll keep mute about the format proposed.)

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Mon, 13 Aug 2018 11:34:26 -0700

> -----Original Message-----
> From: Carsten Bormann <[email-masked]>
> Sent: Sunday, August 12, 2018 2:47 PM
> To: Jim Schaad <[email-masked]>
> Cc: cose <[email-masked]>
> Subject: Re: [COSE] Recharter the COSE working group.
> 
> Hi Jim,
> 
> Interesting initiative.
> 
> > ability to use algorithms which are currently part of TPMs which are
> > widely deployed.  Many of the algorithms for this work are not
> > expected to be IETF recommended algorithms.
> 

Yes I think it would potentially be something to put in the charter.  There is already some work dealing with registration of hash algorithms in the certificate document because it is hard to refer to the hash of a certificate without being able to define which hash function to use.

I do not currently believe that there is a need to define a COSE equivalent to the CMS DigestedData structure at this point.  Given the potential flexibility desired it is probably better to have people do this on an ad hoc basis.

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Aug 2018 21:05:50 +0200

> I do not currently believe that there is a need to define a COSE equivalent to the CMS DigestedData structure at this point.  Given the potential flexibility desired it is probably better to have p…

I agree completely.
So we only need those numbers.
(Maybe including the occasional truncated hash.)

Grüße, Carsten

---

From: Russ Housley <[email-masked]>
Date: Mon, 13 Aug 2018 15:45:36 -0400

I support this recharter activity.  The SUIT WG does not want to specify the use of hash-based signature algorithms with COSE because they have much greater applicability than just signing software packages.  I did write a draft <draft-housley-suit-cose-hash-sig-04> that could be used as a starting point for this portion of the work.

Russ

> On Aug 11, 2018, at 5:03 PM, Jim Schaad <[email-masked]> wrote:
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: "Matthew A. Miller" <[email-masked]>
Date: Mon, 13 Aug 2018 14:11:44 -0600

I also support this effort.  The COSE WG already closed, but that
shouldn't stop the proposed COSEbis WG from using this mailing list
(and/or hopefully just not adopting the -bis suffix).

I am curious what rationales there are for splitting the document.  Not
opposed, mind you; just curious.

- m&m

Matthew A. Miller
< http://goo.gl/LM55L >

---

From: Jim Schaad <[email-masked]>
Date: Mon, 13 Aug 2018 13:52:53 -0700

There are two basic reasons for splitting the document.

First, a shorter document is normally just easier to deal with and by and large one is only dealing with one of the documents at any given time.  (We did get complaints from the IESG at the time about the document length.)

Second, the structure document would not have any algorithm details or recommendations in it.  The issue with having algorithms in a full standard is what happens when that algorithm suddenly because broken.  Do you now need to de-list the standard because it is saying to do things that are no longer recommended?  Having the algorithms separate from the structure make this problem moot.  Protocols that reference the standard and make algorithm requirements would need to deal with this but no the core structure document.

One unimportant reason is that not having the algorithms means that it is going to be easier (I think) to validate that we have implementations of all of the interesting parts of the structure document.

Jim

> From: Matthew A. Miller <[email-masked]>
> Sent: Monday, August 13, 2018 1:12 PM
> To: Russ Housley <[email-masked]>; Jim Schaad
> <[email-masked]>
> Cc: cose <[email-masked]>
> I also support this effort.  The COSE WG already closed, but that shouldn't stop
> the proposed COSEbis WG from using this mailing list (and/or hopefully just not
> adopting the -bis suffix).
> 
> > I support this recharter activity.  The SUIT WG does not want to specify the
> use of hash-based signature algorithms with COSE because they have much
> greater applicability than just signing software packages.  I did write a draft
> <draft-housley-suit-cose-hash-sig-04> that could be used as a starting point for
> this portion of the work.
> >
> > Russ
> >
> >
> >> I have approached the Security ADs about progressing the COSE from
> >> Proposed Standard to Full Standard.  They have indicated that they
> >> would be open to this.  In addition to this, there are a couple of
> >> other documents related to COSE which are looking for homes and this
> >> would provide an opportunity for them to be dealt with as well.
> >>
> >> CBOR Object Signing and Encryption (COSE, RFC 8152) describes how to
> >> create and process signatures, message authentication codes, and
> >> encryption use Concise Binary Object Representation (CBOR, RFC 7049) for
> serialization.
> >> COSE has been picked up and is being used both by a number of groups
> >> within the IETF (i.e. ACE, CORE, ANAMA, 6TiSCH and SUIT) as well as
> >> outside of the IETF (i.e. W3C and FIDO).  There are a number of
> >> implementations, both open source and private,  now in existence.
> >> The specification is now sufficiently mature that it makes sense to try and
> advance it to STD status.
> >>
> >> 1. Should the document be split in two?  One document for the
> >> structures and one document for the algorithm definitions.
> >> 2.  What areas in the document need clarification before the document
> >> can be progressed?
> >> 3.  What implementations exist and do they cover all of the major
> >> sections of the document?
> >>
> >> algorithms that need to be reviewed and published.  The first set of
> >> three are listed in the deliverables.  A re-charter will be required
> >> to expand this list.
> >>
> >> (draft-mcgrew-hash-sigs).  This signature form is resistant to
> >> quantum computing and is low-cost for validation.
> >>
> >> The W3C Web Authentication working group has identified a need for
> >> the ability to use algorithms which are currently part of TPMs which
> >> are widely deployed.  Many of the algorithms for this work are not
> >> 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.
> >>
> >> Key management and binding of keys to identities are out of scope for
> >> the working group.
> >> The specification of algorithms in COSE is limited to those in RFCs
> >> or active IETF WG documents.
> >>
> >> The working group will coordinate its progress with the ACE, SUIT and
> >> CORE working groups to ensure that we are fulfilling the needs of
> >> these constituencies to the extent relevant to their work.
> >> 1. Republishing a version of RFC 8152 suitable for advancement to
> >> full standard.
> >> 4. Define the algorithms needed for W3C Web Authentication for COSE
> >> using draft-jones-webauthn-cose-algorithms and
> >> draft-jones-webauthn-secp256k1 as a starting point.
> >>
> >> I don't currently have a set of milestones associated with this
> >> charter in part because I have not talked to everybody about what
> >> they believe they can do.
> >>
> >> For RFC 8152, assuming that the document is split into two pieces, I
> >> would expect that we should be able to get the split documents to the
> >> IESG prior to the Prague meeting.  Assuming that the IESG requires
> >> that we wait an additional six months of the new document I would
> >> expect that roughly nine months later an updated document could go to the
> IESG for full standard.
> >>
> >> The hash-based signature algorithm document is probably in good
> >> shape, the big question would be should it be coordinated with the
> >> similar documents in the LAMPS working group.  If that is not needed
> >> then this should take less than a year to finish.
> >>
> >> The X.509 certificates draft needs to get review, but I believe that
> >> it is good shape now and probably ready to go.
> >>
> >> I don't know what the state is for the two Web Authentication drafts
> >> as I have not read the first in a while and have never read the second.
> >>
> >> Jim
> >>
> >>
> >>

---

From: "Matthew A. Miller" <[email-masked]>
Date: Tue, 14 Aug 2018 09:20:36 -0600

Thanks Jim,

For whatever it's worth, these are roughly what I thought were
worthwhile reasons to split before I asked.

I wonder if it's really worth waiting for the WG to be formed before
deciding to split, or if consensus to do so can be reached during
chartering.  It seems to me fairly uncontroversial and it can just be
made so now.

I'm confident the directorate reviewers would thank you in addition to
the ADs.

- m&m

Matthew A. Miller
< http://goo.gl/LM55L >