Re: [lamps] [EXTERNAL] X.510

"Erik Andersen" <era@x500.eu> Tue, 24 September 2019 08:28 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 47FD8120115 for <spasm@ietfa.amsl.com>; Tue, 24 Sep 2019 01:28:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 2pY0qw-HK3WJ for <spasm@ietfa.amsl.com>; Tue, 24 Sep 2019 01:28:28 -0700 (PDT)
Received: from smtpscan3.dandomain.dk (smtpscan3.dandomain.dk [194.150.112.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E49120052 for <spasm@ietf.org>; Tue, 24 Sep 2019 01:28:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtpscan3.dandomain.dk (Postfix) with ESMTP id 81251D2C3D for <spasm@ietf.org>; Tue, 24 Sep 2019 10:28:25 +0200 (CEST)
Received: from smtpscan3.dandomain.dk ([127.0.0.1]) by localhost (smtpscan3.dandomain.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05R0oMQucfqi for <spasm@ietf.org>; Tue, 24 Sep 2019 10:28:24 +0200 (CEST)
Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by smtpscan3.dandomain.dk (Postfix) with ESMTP id ADC8BD2C8A for <spasm@ietf.org>; Tue, 24 Sep 2019 10:28:24 +0200 (CEST)
Received: from mail-proxy.dandomain.dk ([194.150.112.64]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id 3201909241028235380; Tue, 24 Sep 2019 10:28:23 +0200
From: Erik Andersen <era@x500.eu>
To: 'LAMPS' <spasm@ietf.org>
Cc: Jean-Paul LEMAIRE <jean-paul.lemaire@univ-paris-diderot.fr>, Mark Pecen <mark.pecen@isara.com>
References: <000601d57081$5afa8fc0$10efaf40$@x500.eu> <01fd886909e94b0ab9c353958f46a45e@PMSPEX05.corporate.datacard.com>
In-Reply-To: <01fd886909e94b0ab9c353958f46a45e@PMSPEX05.corporate.datacard.com>
Date: Tue, 24 Sep 2019 10:28:23 +0200
Message-ID: <002201d572b2$0815f6e0$1841e4a0$@x500.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQISoDp2LBZNpXW83TH/US3RFiUrOAFnm8W/prTjbiA=
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/SuQVoZTK3gIaIGSidBdJZuugDs0>
Subject: Re: [lamps] [EXTERNAL] X.510
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, 24 Sep 2019 08:28:30 -0000

Hi Mike,

A good point. Having multiple algorithms for added security and not just for
migration is not really considered in draft X.510, which could be a miss. We
will see if we can get that aspect into document during its final ballot
round where in principle only editorials are allowed. Anyway, we will
probably need an edition 2 quite quickly.

Best regards,

Erik

-----Oprindelig meddelelse-----
Fra: Spasm [mailto:spasm-bounces@ietf.org] På vegne af Mike Ounsworth
Sendt: 24 September 2019 05:51
Til: Erik Andersen <era@x500.eu>; LAMPS <spasm@ietf.org>
Emne: Re: [lamps] [EXTERNAL] X.510

Hi Erik,

I found your slides
https://docbox.etsi.org/Workshop/2019/201906_ETSISECURITYWEEK/202106_Dynamic
NatureOfTechno/SESSION03_CHANGINGCRYPTOGRAPHY/ANDERSENSLSERVICES_ANDERSEN.pd
f, explaining the rationale behind X.510. In it, you say:

* A back level recipient will ignore the alternative algorithm, but validate
according to the native one
* An advanced recipient will validate according to the alternative algorithm

In attending post-quantum conferences, for example the NIST PQC, there is a
strong call for "hybrid" modes where *both* algorithms are validated because
we don't fully trust the new stuff yet. So this may not be simply a
migration issue, but a more long-term issue of combining algorithms for
increased security.
Do you have an opinion on whether X.510 in its current form would be
appropriate for hybrid modes, and whether your language should be adjusted
to be "native algorithm and alt algorithm" as opposed to your current
"native algorithm or alt algorithm" ?

- - -
Mike Ounsworth | Office: +1 (613) 270-2873

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Erik Andersen
Sent: Saturday, September 21, 2019 8:35 AM
To: LAMPS <spasm@ietf.org>
Subject: [EXTERNAL][lamps] X.510

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the
content is safe.
________________________________________
Within ITU-T and ISO we have developed a new specification, Rec. ITU-T X.510
| ISO/IEC 9594-11, which now is out for final vote. There is a link to it
https://www.dropbox.com/s/qzzuy9hu2vjz9qw/X.510-dis.pdf?dl=0. We expect to
complete it by March 2020.

Any comment any of you might have will be highly appreciated.

Best regards,

Erik

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm