Re: [COSE] Recharter the COSE working group.

["Matthew A. Miller" <[e-mail]>]

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 >

On 18/08/13 13:45, Russ Housley wrote:
> 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 <[e-mail]> wrote:
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> COSE mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cose
> 
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose
>