Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS?

Benjamin Kaduk <kaduk@mit.edu> Thu, 23 January 2020 23:22 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F7C1200F9 for <secdispatch@ietfa.amsl.com>; Thu, 23 Jan 2020 15:22:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 OR-0P4Djdgqo for <secdispatch@ietfa.amsl.com>; Thu, 23 Jan 2020 15:22:18 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AB0A1200BA for <secdispatch@ietf.org>; Thu, 23 Jan 2020 15:21:56 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00NNLpRh027012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Jan 2020 18:21:54 -0500
Date: Thu, 23 Jan 2020 15:21:51 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Markku-Juhani O. Saarinen" <mjos@pqshield.com>
Cc: Eric Rescorla <ekr@rtfm.com>, Michael Richardson <mcr+ietf@sandelman.ca>, IETF SecDispatch <secdispatch@ietf.org>
Message-ID: <20200123232151.GA90660@kduck.mit.edu>
References: <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> <DM6PR11MB3883DB8289E4EE1CDEFE7BA89B310@DM6PR11MB3883.namprd11.prod.outlook.com> <3140.1579364674@localhost> <CABcZeBPfGmnkDU-7ot43hC2E7XvB0XeAFFEmsST4S_Hk1GgOFg@mail.gmail.com> <15967.1579382030@localhost> <CABcZeBMWu+Zd_+=gvcc328fm87B1RsxnUaH2HpYbp9Wv_OMUYQ@mail.gmail.com> <24181.1579453158@localhost> <CAPwdP4PkVfKbg=nCvjDTyGfbc-CiT2PGrdxt-c2b5dDK4903qA@mail.gmail.com> <CABcZeBMduM8bB0vWazb31ccQ6J=L4jNoOuiKeOFM9AafkShyNw@mail.gmail.com> <CAPwdP4N+f+xBZnGTKf8kb-TkOZdBb6iGTKncR6Gqbd0OhpxGvw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAPwdP4N+f+xBZnGTKf8kb-TkOZdBb6iGTKncR6Gqbd0OhpxGvw@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/J05dkq9R4tk6uhw9Q-4hLtcreKg>
Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS?
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2020 23:22:19 -0000

On Mon, Jan 20, 2020 at 02:40:15PM +0000, Markku-Juhani O. Saarinen wrote:
> 
> A couple of additional technical points:
> - The reason why I mentioned SHA3/SHAKE for RSA and ECC is that this would
> seem to allow message hashing to be performed only once, rather than twice
> (at least for Dilithium and Falcon).
>  - We don't see this as being as widely used for TLS server authentication
> as for smart cards, secure elements and similar applications that can't
> just switch or negotiate certificate chains on the fly. I work on the
> hardware side myself and especially there we have additional considerations
> such as hardcoded cert chains and FIPS certification, which is currently
> only available for the hybrid case. I wouldn't want to leave the issuance
> of OIDs for this purpose at the mercy of TLS folks, which is just one of
> many applications of this format.

Isn't that the point of OIDs, though, that no one is at the mercy of anyone
else, and can just mint their own OIDs as needed?

-Ben