Re: [lamps] Problems with the current ALGORITHM information object class

Erik Andersen <era@x500.eu> Tue, 12 May 2020 15:58 UTC

Return-Path: <era@x500.eu>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6BA3A0B95 for <spasm@ietfa.amsl.com>; Tue, 12 May 2020 08:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Level:
X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=x500.eu
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 uEtXPXveewKT for <spasm@ietfa.amsl.com>; Tue, 12 May 2020 08:58:57 -0700 (PDT)
Received: from outscan1.mf.dandomain.dk (outscan1.mf.dandomain.dk [212.237.249.58]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63053A0C19 for <spasm@ietf.org>; Tue, 12 May 2020 08:58:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by outscan1.mf.dandomain.dk (Postfix) with ESMTP id 2092F4068AB9; Tue, 12 May 2020 17:58:53 +0200 (CEST)
Received: from outscan1.mf.dandomain.dk ([127.0.0.1]) by localhost (outscan1.mf.dandomain.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4lGTsPuQjCH; Tue, 12 May 2020 17:58:51 +0200 (CEST)
Received: from mail-proxy.dandomain.dk (dilvs03.dandomain.net [194.150.112.64]) by outscan1.mf.dandomain.dk (Postfix) with ESMTPA id 8267E4068AAC; Tue, 12 May 2020 17:58:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=x500.eu; s=dandomain; t=1589299131; bh=ATRLkyaMO2hpGu+142+Grmife5pk5U4RVFUHqWCCXUg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From; b=msUYkEJI7IkeHrS+cQivfFb3CUYVMrX4aTe+6MJUqkhSymEKmK9Abis0a31w1KJSL VUIJtnT8fCihiuy/VgRNCR7r+3gaVdmvaHr5+CQ9D5xB83pDeGcS9PtYsC/omt7V/g /bmqbbTcRwmskaumH9NQbSvH33051G1sVIq0dRkOA9QIbV8YPxx9LVwt1RYBYmiLB+ y2OKDh4AMi3swZiqmuDkAk6UC5OfhFP8hJ415iFvda1sWVnAKfPRGzRqGeaOuNMAVC 07CF7typ/1DeSEEhJEd8lbFnAKdIP5MDPXneQP86tcCU2RDwwvS1tU7pSNccHh8xq/ 1eD7lgL2P9J3A==
From: Erik Andersen <era@x500.eu>
To: 'Russ Housley' <housley@vigilsec.com>, 'Rich Salz' <rsalz@akamai.com>
Cc: 'LAMPS' <spasm@ietf.org>
References: <000001d62762$8385a360$8a90ea20$@x500.eu> <97737DBD-54DB-4336-A387-E22C59E78B11@vigilsec.com> <001f01d6285c$d614adb0$823e0910$@x500.eu> <15833649-2B4C-49ED-9ACD-6F9AF9B41FFD@vigilsec.com> <B9ABCF64-ABE3-423D-8CE2-2BE79A6D1DF8@akamai.com> <697D575A-B0BA-4BA5-B5F6-10ACF3E6C6B4@vigilsec.com>
In-Reply-To: <697D575A-B0BA-4BA5-B5F6-10ACF3E6C6B4@vigilsec.com>
Date: Tue, 12 May 2020 17:58:48 +0200
Message-ID: <002301d62876$3b1f5750$b15e05f0$@x500.eu>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01D62886.FEAA7140"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGsSWEsGbi5WzyRcw86Ep3rBlnkMwIwrpU6Ai4BHRYB4xM3wQG2KIYmAjRDVbKopvOS4A==
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/oqSZ0RHH9ewXcKmWGhQTLjCJq9k>
Subject: Re: [lamps] Problems with the current ALGORITHM information object class
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2020 15:59:00 -0000

Thanks for your replies. We have OID structure that potentially could be used: { joint-iso-itu-t ds(5) algo(42) }. This gives rather short OIDs, although a couple of more levels will be needed for organizing the OIDs in a structured way. 

 

Erik

 

From: Russ Housley <housley@vigilsec.com> 
Sent: 12 May 2020 17:00
To: Rich Salz <rsalz@akamai.com>
Cc: Erik Andersen <era@x500.eu>; LAMPS <spasm@ietf.org>
Subject: Re: [lamps] Problems with the current ALGORITHM information object class

 

 





On May 12, 2020, at 10:56 AM, Salz, Rich <rsalz@akamai.com <mailto:rsalz@akamai.com> > wrote:

 

 

*	However, I do not advocate a change that breaks  backward compatibiliy.

*	Sure, there could be an interworking problem, but it can be handled. Implementations of a standard specifying the original algorithm will still interwork. Implementations of a standard specifying the modified algorithm will also interwork.

 

So algorithms that want to use the new constructs, *even if they are the same such as AES 128 GCM* will use a new OID?  If so, that’s okay with me.

 

New OIDs would be needed in my suggestions, otherwise there would be confusion about the parameter structure.

 

Russ