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

"Santosh Chokhani" <santosh.chokhani@gmail.com> Tue, 03 October 2017 20:48 UTC

Return-Path: <santosh.chokhani@gmail.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 77A15134212; Tue, 3 Oct 2017 13:48:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 n8OT959wCdl8; Tue, 3 Oct 2017 13:48:35 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB203133073; Tue, 3 Oct 2017 13:48:34 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id d67so6171491qkg.5; Tue, 03 Oct 2017 13:48:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=oxvyfpIYVsvKNGw3dY43IsIQw9gG1Ghxsu1Qxu6oGkc=; b=Ks0RQRz+xbWEvUYJyeiEVItYa9GWPP+HggW9+gUiKKGJ+yNRhIYYIl7CtzbiyUrilI WIrIM0pvemx7ncs4FKjDr5Cph4zei8r2oOM+eLquPEhWqldw9hcsD9Tv+IUfxbZju5Dk 4jCBXO98LqGAnM30N5YEGrr/RumC/oJW4T/J47wFd0PZvMY+kOYFgrhPGBOEPiekhp77 +iVoStLBQp71kjCk9Kz4NbGHsEmmeBk7tmu/CCcBkYDKW8gQJfGdVbkctRmFeJ2d4uwz ssvykPCyOyqGOiU3wekjBWZ1Ncj8P8HXBWcOmbZLeSWl92k4VNlos3QUoQUhYrJERz6E dCNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=oxvyfpIYVsvKNGw3dY43IsIQw9gG1Ghxsu1Qxu6oGkc=; b=r36YJlukQyuAQExLoXD8zMwN/FPt8Mahm7+RdXYjgCrc74rqu5uJaGQyJMdru7n4e6 g01PvQKw3zADW+RJGc8zVxexbv59sePuWtHK6dOoS4G1KWYdzAL4KKNfO3SxEaYn15ZD xD3h5FnCGvkj2btl72WCOdNyLGRyOBCIGEb5s6F5PRQ7WwPBY+Q1iN/6ZGveFU12jRJS BuInWx8CusFo8NyJglAQlP7LlgZ4vpOKGHrZy+eAskaL7ww6Qd7UjQK8OZxBCY4Tk2DB bbz1K1kO1jB3jXt4d1svYM5P9ovfrXmzWclj01PDOfDNuvGj2mf2dqrEx45GCWdPUSgY FJMw==
X-Gm-Message-State: AMCzsaWuoT8eDBp4yTVV8SFxx7ZNbSyyAZcN+qhUpAzn23shKFWU3R05 8qTybjV/wURZHFY857rfvIw=
X-Google-Smtp-Source: AOwi7QDllFl4Jn4EVEIZ0cQr+OGLfpiMT3oaGgWJToLVJErI/lKuTVy4EpZLtAmcAq+OWz1eVGPGMg==
X-Received: by 10.55.21.30 with SMTP id f30mr23097809qkh.335.1507063713412; Tue, 03 Oct 2017 13:48:33 -0700 (PDT)
Received: from SantoshBrain (pool-173-73-191-59.washdc.fios.verizon.net. [173.73.191.59]) by smtp.gmail.com with ESMTPSA id 49sm9414815qtq.1.2017.10.03.13.48.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Oct 2017 13:48:32 -0700 (PDT)
From: Santosh Chokhani <santosh.chokhani@gmail.com>
To: 'Alexander Truskovsky' <Alexander.Truskovsky@isara.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
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>
In-Reply-To: <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com>
Date: Tue, 03 Oct 2017 16:48:33 -0400
Message-ID: <079001d33c88$fab856c0$f0290440$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQDus9F8NjCdvUGnLuU9orle20/kKgI84QjmAbyZK6EBM7nHTKRyPsZA
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/ULOddeM6kCzvVFXyHjcbTBmyWTs>
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 20:48:37 -0000

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