IETF Logo Mail Archive

Re: [COSE] tstr values for kty, alg, crv, etc.

Carsten Bormann <cabo@tzi.org> Sun, 08 August 2021 11:48 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1D33A26F2 for <cose@ietfa.amsl.com>; Sun, 8 Aug 2021 04:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoWKeUeC1sBd for <cose@ietfa.amsl.com>; Sun, 8 Aug 2021 04:48:40 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65633A26F1 for <cose@ietf.org>; Sun, 8 Aug 2021 04:48:39 -0700 (PDT)
Received: from smtpclient.apple (ip-109-42-115-93.web.vodafone.de [109.42.115.93]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GjHXy664kz2xKT; Sun, 8 Aug 2021 13:48:34 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail-8D891DED-134B-4A5D-92ED-FE4531E3E7A7"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAFWvErXkR1vVNQFjn+rVCe8jaJ7DspBUq5kVJdGzonBU98Ctbw@mail.gmail.com>
Date: Sun, 08 Aug 2021 13:48:34 +0200
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, cose@ietf.org, Laurence Lundblade <lgl@island-resort.com>, jodonogh@qti.qualcomm.com
Message-Id: <78EB5028-71BD-4034-A9B3-340E206F1F90@tzi.org>
References: <CAFWvErXkR1vVNQFjn+rVCe8jaJ7DspBUq5kVJdGzonBU98Ctbw@mail.gmail.com>
To: AJITOMI Daisuke <ajitomi@gmail.com>
X-Mailer: iPhone Mail (18G82)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/VS5x-3iTCUAqVT1Z9rAzr74TfWU>
Subject: Re: [COSE] tstr values for kty, alg, crv, etc.
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Aug 2021 11:48:46 -0000

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 <ajitomi@gmail.com> 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 <mcr+ietf@sandelman.ca>:
>> 
>> Laurence Lundblade <lgl@island-resort.com> 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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>>            Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email