Re: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI"

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 04 October 2017 00:58 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 9FA64132EC4; Tue, 3 Oct 2017 17:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 hpPG2IxATimV; Tue, 3 Oct 2017 17:58:42 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8B513321F; Tue, 3 Oct 2017 17:58:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EE8C1BEC3; Wed, 4 Oct 2017 01:58:38 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNnCjuny-IVc; Wed, 4 Oct 2017 01:58:35 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C8F70BEBB; Wed, 4 Oct 2017 01:58:34 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507078715; bh=VjmvQIbLooq3i7B2aINor9IfW/RvgUTOxCH87LSh7Nw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=HxAZHb6RryHvZk2BMHAAqaW7lRFdvZ8JDprkbfd7sPfG8j2+3JGnXsHSiFZhuao8X h1AFY1D9TrM+vutygMROLHiEND723gedUMpiPWFqEZ/03haa6fqlqVdJykOCNrk9Rt ht6RhMOYoBRfJsqbeF/AhgaYsiTPUuop5CDhsiOI=
To: Alexander Truskovsky <Alexander.Truskovsky@isara.com>, "santosh.chokhani@gmail.com" <santosh.chokhani@gmail.com>, "david.waltermire@nist.gov" <david.waltermire@nist.gov>, "kivinen@iki.fi" <kivinen@iki.fi>, "housley@vigilsec.com" <housley@vigilsec.com>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "ekr@rtfm.com" <ekr@rtfm.com>, "Scott.Mansfield@Ericsson.com" <Scott.Mansfield@Ericsson.com>, "spasm@ietf.org" <spasm@ietf.org>, "Kathleen.Moriarty.ietf@gmail.com" <Kathleen.Moriarty.ietf@gmail.com>, "itu-t-liaison@iab.org" <itu-t-liaison@iab.org>, "jean-paul.lemaire@univ-paris-diderot.fr" <jean-paul.lemaire@univ-paris-diderot.fr>
References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <d2af8314-753d-26ab-5f5c-e5102ae08a0f@cs.tcd.ie>
Date: Wed, 04 Oct 2017 01:58:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="ODOjdUHNBLwp07uTAcdCIwUdcPEkt5CE7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/CPi9fYQINfAurObNvbg3uH-lf-Q>
X-Mailman-Approved-At: Thu, 05 Oct 2017 13:31:13 -0700
Subject: Re: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI"
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 04 Oct 2017 00:58:46 -0000

Hiya,

On 03/10/17 21:38, Alexander Truskovsky wrote:
> This allows X.509 certificates to contain two (or more) public keys
> and issuer signatures.  The goal would be to ease the migration of
> PKI and dependent protocols to new digital signature algorithms.  The
> motivation was to make the X.509 more cryptographically agile and
> simplify the migration to quantum-safe algorithms, but it is
> algorithm agnostic.  The main benefit of this proposal is that
> current systems will be able to use these newer X.509 certificates as
> they do today without any modifications, while systems that were
> updated to support quantum-safe algorithms can also be updated to
> understand the newer X.509 format and use quantum-safe algorithm
> instead.

I don't believe the "without any modifications" claim. If that
were true, then the additional (hopefully) quantum-safe keys or
signatures would be mere chaff.

I do wonder though if it could be that the advent of a desire
for post-quantum signatures is the straw that breaks the X.509
camel's back. For example, with a view to making X.509-based
PKI evolution end up sufficiently more expensive compared to
displacing X.509 entirely. It'll be fun to see what happens
as things pan out.

One reason that that might be the case is that the

S.


> 
> We are working on a draft that mirrors the ITU-T’s work with a few
> partners and will publish it for review soon.
> 
> Alex
> 
> 
> On 2017-10-02, 9:58 PM, "IPsec on behalf of Santosh Chokhani"
> <ipsec-bounces@ietf.org on behalf of santosh.chokhani@gmail.com>
> wrote:
> 
> I am not sure I understand what is being said below.  The link to the
> PDF does not add to the message body.
> 
> If there is a concern about what signature algorithm is used for what
> type of subject key, X.509 already has that flexibility.
> 
> If there is a concern about using multiple signatures on an X.509 
> certificate, one can use the single signature algorithm identifier to
> define multiple algorithms, parameters, and signatures.
> 
> -----Original Message----- From: Spasm
> [mailto:spasm-bounces@ietf.org] On Behalf Of Liaison Statement 
> Management Tool Sent: Wednesday, September 13, 2017 11:25 AM To:
> David Waltermire <david.waltermire@nist.gov>; Tero Kivinen 
> <kivinen@iki.fi>; Russ Housley <housley@vigilsec.com> Cc: Limited
> Additional Mechanisms for PKIX and SMIME Discussion List 
> <spasm@ietf.org>; Eric Rescorla <ekr@rtfm.com>; Russ Housley 
> <housley@vigilsec.com>; Tero Kivinen <kivinen@iki.fi>; Scott
> Mansfield <Scott.Mansfield@Ericsson.com>; IP Security Maintenance and
> Extensions Discussion List <ipsec@ietf.org>; Kathleen Moriarty 
> <Kathleen.Moriarty.ietf@gmail.com>; David Waltermire 
> <david.waltermire@nist.gov>; itu-t-liaison@iab.org; 
> jean-paul.lemaire@univ-paris-diderot.fr Subject: [lamps] New Liaison
> Statement, "LS on ITU-T SG17 work on quantum-safe PKI"
> 
> Title: LS on ITU-T SG17 work on quantum-safe PKI Submission Date:
> 2017-09-13 URL of the IETF Web page:
> https://datatracker.ietf.org/liaison/1541/
> 
> From: Jean-Paul Lemaire <jean-paul.lemaire@univ-paris-diderot.fr> To:
> David Waltermire <david.waltermire@nist.gov>,Tero Kivinen 
> <kivinen@iki.fi>,Russ Housley <housley@vigilsec.com> Cc: David
> Waltermire <david.waltermire@nist.gov>,IP Security Maintenance and 
> Extensions Discussion List
> <ipsec@ietf.org>,itu-t-liaison@iab.org,Limited Additional Mechanisms
> for PKIX and SMIME Discussion List <spasm@ietf.org>,Russ Housley
> <housley@vigilsec.com>,Scott Mansfield 
> <Scott.Mansfield@Ericsson.com>,Kathleen Moriarty 
> <Kathleen.Moriarty.ietf@gmail.com>,Tero Kivinen
> <kivinen@iki.fi>,Eric Rescorla <ekr@rtfm.com> Response Contacts: 
> jean-paul.lemaire@univ-paris-diderot.fr Technical Contacts: Purpose:
> For information
> 
> Body: ITU-T Study Group 17 is pleased to inform you that in our 
> August/September 2017 meeting we agreed to start work on the
> inclusion of a proposal to include optional support for multiple
> public-key algorithms in Recommendation ITU-T X509 | ISO/IEC 9594-8.
> 
> The industry is preparing ICT systems to be resistant to attacks by 
> large-scale quantum computers in addition to more sophisticated
> attacks by conventional computing resources. Proposed was an optional
> feature to the X.509 certificate that provides a seamless migration
> capability to existing PKI systems, and is completely backwardly
> compatible with existing systems.
> 
> While public-key key establishment algorithms are typically
> negotiated between peers and are generally fairly simple to update,
> the authentication systems typically rely on a single digital
> signature algorithm which are more difficult to update. This is
> because of the circular dependency between PKI-based identity systems
> and the dependent communication protocols. In order to update a PKI
> system, one would typically need to create a duplicate PKI system
> that utilizes a new digital signature algorithm and then migrate all
> the dependent systems one by one.
> 
> This proposal eliminates the need to create such duplicate PKI
> systems by adding optional extensions to contain alternate public key
> and alternate signature, and a method for the CA to sign certificates
> using a layered approach to ensure that every attribute is
> authenticated by both signatures. The resulting certificate, while
> containing new quantum safe public key and signature, can still be
> used by existing systems relying on the classic public key and
> signature. Attachments:
> 
> sp16-sg17-oLS-00068
> 
> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-09-13-itu-t-sg-17
>
> 
-ipsecme-lamps-ls-on-itu-t-sg17-work-on-quantum-safe-pki-attachment-1.pdf
> 
> _______________________________________________ Spasm mailing list 
> Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
> 
> _______________________________________________ IPsec mailing list 
> IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
> 
> 
> 
> 
> _______________________________________________ Spasm mailing list 
> Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
>