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

Alexander Truskovsky <Alexander.Truskovsky@isara.com> Tue, 03 October 2017 21:35 UTC

Return-Path: <Alexander.Truskovsky@isara.com>
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 523C013219B; Tue, 3 Oct 2017 14:35:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=unavailable 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 8wl1ew-kmftw; Tue, 3 Oct 2017 14:35:12 -0700 (PDT)
Received: from esa1.isaracorp.com (esa1.isaracorp.com [207.107.152.166]) by ietfa.amsl.com (Postfix) with ESMTP id DA7FA1331DC; Tue, 3 Oct 2017 14:35:11 -0700 (PDT)
Received: from 172-1-110-12.lightspeed.sntcca.sbcglobal.net (HELO cas.isaracorp.com) ([172.1.110.12]) by ip1.isaracorp.com with ESMTP; 03 Oct 2017 21:40:49 +0000
Received: from mb.isaracorp.com (2002:ac01:6e0b::ac01:6e0b) by mb.isaracorp.com (2002:ac01:6e0b::ac01:6e0b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 3 Oct 2017 17:35:04 -0400
Received: from mb.isaracorp.com ([fe80::9056:5d62:46d0:fe1f]) by mb.isaracorp.com ([fe80::9056:5d62:46d0:fe1f%12]) with mapi id 15.00.1044.021; Tue, 3 Oct 2017 17:35:04 -0400
From: Alexander Truskovsky <Alexander.Truskovsky@isara.com>
To: Santosh Chokhani <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: "spasm@ietf.org" <spasm@ietf.org>, "ekr@rtfm.com" <ekr@rtfm.com>, "Scott.Mansfield@Ericsson.com" <Scott.Mansfield@Ericsson.com>, "ipsec@ietf.org" <ipsec@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>
Thread-Topic: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI"
Thread-Index: AQHTO+sV5+bpPT0iyE2onk66kRVilaLSoMOAgAA5gICAAALogIAADP8A
Date: Tue, 03 Oct 2017 21:35:04 +0000
Message-ID: <070920B4-ED3D-44F1-BC72-60FDB74D78EA@isara.com>
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> <079001d33c88$fab856c0$f0290440$@gmail.com>
In-Reply-To: <079001d33c88$fab856c0$f0290440$@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.25.5.208]
Content-Type: text/plain; charset="utf-8"
Content-ID: <A1D22685475BFD489E13FA1435F19CBC@isaracorp.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/nqYTAl39Z1aCVuTDDA6qQ3-vcpw>
X-Mailman-Approved-At: Tue, 03 Oct 2017 16:43:20 -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: Tue, 03 Oct 2017 21:35:15 -0000

Thank you for your comment.

We want to ensure the existing systems can use these newer certificates as if nothing changed.  That’s the key requirement.  If the Signature field is modified, the systems that have not been updated will not be able to use classic algorithms as they do today.  Placing signatures in the non-critical extensions leaves the Signature field untouched.

Alex

On 2017-10-03, 4:48 PM, "Santosh Chokhani" <santosh.chokhani@gmail.com> wrote:

    Multiple public keys as well as signatures can be accommodated using the respective algorithm OIDs in Signature and SPKI fields.
    
    Have you considered that in place of using an extension.
    
    -----Original Message-----
    From: Alexander Truskovsky [mailto:Alexander.Truskovsky@isara.com] 
    Sent: Tuesday, October 3, 2017 4:38 PM
    To: santosh.chokhani@gmail.com; david.waltermire@nist.gov; kivinen@iki.fi; housley@vigilsec.com
    Cc: spasm@ietf.org; ekr@rtfm.com; housley@vigilsec.com; Scott.Mansfield@Ericsson.com; ipsec@ietf.org; Kathleen.Moriarty.ietf@gmail.com; itu-t-liaison@iab.org; jean-paul.lemaire@univ-paris-diderot.fr
    Subject: Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI"
    
    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.
    
    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