Subject: [COSE] New option going forward for COSE struct

From: Jim Schaad <[email-masked]>
Date: Mon, 24 Aug 2020 09:17:31 -0700

At the virtual IETF meeting where had a long discussion on how the structure
document should progress without getting any type of final conclusions.
Since that time I have come up with a new option which I think should be
added to the discussion.

1.  Have a single document with the new countersignature algorithm added.
This has the advantage that everything is in one place, it is easy to tag
the current countersignature algorithm header parameters as deprecated
because there is a new replacement in the document.

2.  Have two documents (version 1):  Fix the description of the current
countersignature algorithm in the bis document and progress that.  Create a
new document which contains the new countersignature algorithm.  This would
be an odd choice because I am not sure how the current countersignature
algorithm should be tagged.  Not deprecating seems wrong but trying to
deprecate later also seems to be a strange thing to do.

3.  Have two documents (version 2): Pull the current countersignature
algorithm out of the core document and allow it to progress to full standard
without a countersignature algorithm at all.  Create a new document with
both the new and old countersignature algorithms tagging the old one as
deprecated.  This can then be added to the STD number in the future.

4. Have two documents (version 3): Pull the current countersignature
algorithm out of the core document and add the new countersignature
algorithm to it.  Create  new document which contains the old
countersignature algorithm and publish it as historical.  This is cleaner in
many respects as the deprecated version of the countersignature algorithm
would be in a document which is clearly marked as not being what is to be
used.

5. Have three documents:  Pull the current countersignature algorithm out of
the core document and advance it to full standard.  Create two new
documents, one for each of the countersignature algorithms.  The old
countersignature algorithm would be published as historic and the new
document can be cycled as needed until it is ready and then added to the STD
number as a second document.

I suggested the last option to the chairs in a private email mostly as an
option that exists but I was not really serious about it.  However, in
retrospect I am starting to warmup to the way of doing things as it has
several advantages.  The current structure document can progress without any
big problems.  (Yes I still need to deal with Ben's discuss, but it is kind
of meta.)  It also means that the two countersignature algorithms are
separated and clearly marked in the RFCs themselves as to what there
statuses are.  There are no issues with having multiple documents in the
full standard so adding the countersignature v2 document later is not a
problem.

Jim

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 Aug 2020 12:24:51 -0400

As I said on the call, I think that one document is better, even if it causes a short delay for progress of the I-D toward RFC.

Russ

> On Aug 24, 2020, at 12:17 PM, Jim Schaad <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 24 Aug 2020 09:42:56 -0700

> As I said on the call, I think that one document is better, even if it causes a short delay for progress of the I-D toward RFC.

IIUC, the "one document" approach would lead to a more-than-short delay in
STD number assignment.

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Aug 2020 13:09:25 -0400

> Since that time I have come up with a new option which I think should be

You have five choices, but I think that I there are actually two decisions:

a) the base document will advance with:
   1) no countersignature algorithm
   2) the old(current) countersignature algorithm
   3) the new countersignature algorithm

b) one or two documents will be created to document and deprecrate the old
   algorithm, and document the new way.

    > number as a second document.

This is A1, and B-with-two-documents.
I am fine with that in the end.

Russ Housley <[email-masked]> wrote:
    > As I said on the call, I think that one document is better, even if it
    > causes a short delay for progress of the I-D toward RFC.

I estimate it will be a six month delay.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jim Schaad <[email-masked]>
Date: Mon, 24 Aug 2020 10:19:51 -0700

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Monday, August 24, 2020 9:43 AM
To: Russ Housley <[email-masked]>
Cc: Jim Schaad <[email-masked]>; cose <[email-masked]>
Subject: Re: [COSE] New option going forward for COSE struct

[JLS] I tend to agree with Ben on this.  Stripping out all of the
countersignature text could move the document back to the IESG by the end of
September and then into the RFC Editor queue.  Adding the new text means
back to the IESG probably in Nov, add a new IETF last call and then, at
least for me to feel comfortable about it, a one year minimum wait before
moving the document up to full standard.  I am not sure that I would
consider 18 months at a minimum as a short delay.

Jim

-Ben

---

From: "Matthew A. Miller" <[email-masked]>
Date: Mon, 24 Aug 2020 16:43:02 -0600

Speaking with no hat ...

My personal preference would be to deprecate counter-signatures from
-struct so it can progress, and document the v2 in a separate document.
 I have small personal preference for deprecating the v1
counter-signature in -struct while keeping its process documented, but
it's a small preference.

I'm in favor of two documents, but not three.  For me, I think that
means either counter-signatures are consolidated into a single document,
or the v1 is left in RFC 8152.  As a radical opinion, maybe consider
leaving the v1 mechanism behind in RFC 8152 and only discuss its
deprecation in -struct.

- m&m

Matthew A. Miller

On 20/08/24 10:17, Jim Schaad wrote:
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose
>