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: > 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 > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
