This discussion is all a bit short sighted to me. Sure, we can advise against registering text labels now. But COSE has a long life with many applications before it, some of which may be outside what you are thinking about now. What’s the rush on disabling these?
Sent from mobile, sorry for terse > On 8. Aug 2021, at 10:15, AJITOMI Daisuke <[email protected]> wrote: > > > > We can deprecate tstr as key. > > We can say that no signer MUST NEVER emit this again. > > We can say that a verifier MAY accept tstr as a key. > > This sounds reasonable to me. > > Since any tstr labels are not registered in the IANA registry for now and > there are no implementations that support the tstr labels as far as I know, > > I think there is room to make the tstr labels deprecated. > > Thanks, > Daisuke > > 2021年8月8日(日) 8:22 Michael Richardson <[email protected]>: >> >> Laurence Lundblade <[email protected]> wrote: >> > I don’t think tstr can be removed from the standard. That would break >> > backwards compatibility. Maybe a strong recommendation could be added >> > with the comment that many implementations don’t support tstr. >> >> Any system built upon COSE that does not support tstr as a key is already >> broken if many implementations don't support it. >> >> We can deprecate tstr as key. >> We can say that no signer MUST NEVER emit this again. >> We can say that a verifier MAY accept tstr as a key. >> >> > There is a revision of 8152 in process right now called 8152bis. That >> > seems like the place to do it. >> >> It is pretty late to do this. 8152bis is in AUTH48, we need the proxy-author >> and WG chairs to agree to this immediately. >> >> I agree that having two ways things is not a good thing. >> >> -- >> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) >> Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
