Re: [lamps] Draft LAMPS Recharter
Daniel Van Geest <Daniel.VanGeest@isara.com> Mon, 04 June 2018 16:08 UTC
Return-Path: <Daniel.VanGeest@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 3FC70126F31 for <spasm@ietfa.amsl.com>; Mon, 4 Jun 2018 09:08:16 -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, HTML_MESSAGE=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 O1pC0F_oStnK for <spasm@ietfa.amsl.com>; Mon, 4 Jun 2018 09:08:13 -0700 (PDT)
Received: from esa2.isaracorp.com (esa2.isaracorp.com [207.107.152.176]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1C312DFB0 for <spasm@ietf.org>; Mon, 4 Jun 2018 09:08:13 -0700 (PDT)
Received: from 172-1-110-12.lightspeed.sntcca.sbcglobal.net (HELO cas.isaracorp.com) ([172.1.110.12]) by ip2.isaracorp.com with ESMTP; 04 Jun 2018 16:08:12 +0000
Received: from V0501WEXGPR02.isaracorp.com (10.5.9.20) by V0501WEXGPR01.isaracorp.com (10.5.8.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1466.3; Mon, 4 Jun 2018 12:07:52 -0400
Received: from V0501WEXGPR02.isaracorp.com ([fe80::d7:9d13:5f34:537a]) by V0501WEXGPR02.isaracorp.com ([fe80::d7:9d13:5f34:537a%6]) with mapi id 15.01.1466.003; Mon, 4 Jun 2018 12:07:52 -0400
From: Daniel Van Geest <Daniel.VanGeest@isara.com>
To: Russ Housley <housley@vigilsec.com>, LAMPS <spasm@ietf.org>
Thread-Topic: [lamps] Draft LAMPS Recharter
Thread-Index: AQHT4iO3uwvg8Cvq7E6irBle105/3aRQ3K8A
Date: Mon, 04 Jun 2018 16:07:52 +0000
Message-ID: <D0C10B32-4C0A-45E9-97D1-17DAAEA95D9A@isara.com>
References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com>
In-Reply-To: <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.5.17.205]
Content-Type: multipart/alternative; boundary="_000_D0C10B324C0A45E997D117DAAEA95D9Aisaracom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/an7sS81Qc6wa4f9VayGFd2YTOwc>
Subject: Re: [lamps] Draft LAMPS Recharter
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: Mon, 04 Jun 2018 16:08:18 -0000
Hi WG, We noticed that draft-truskovsky-lamps-pq-hybrid-x509 was put up for consideration as a potential topic for LAMPS recharter, but hasn't been included in the recharter text. It was favorably received in London and there were good points raised, especially regarding how to use these extensions in interactive protocols such as TLS. If there is support for continuing with the draft, we plan on updating it with ideas we've been considering to optimize the extensions' usage in interactive protocols. There was also support for the draft in the responses to the call for potential recharter topics on the WG mailing list, so I've included some potential charter text here in case the group would like to progress further with it: Specify a set of certificate extensions that are used to embed an alternative public key and/or signature within a certificate, certificate signing request or certificate revocation list. These extensions allow a public key infrastructure to incrementally migrate to a new public key signature algorithm without needing to support parallel certificate chains, while maintaining backwards compatibility with systems using the existing algorithms. As Panos mentioned, this work is agnostic of NIST PQ algorithms, and it is important to be ready to start migrating when the algorithms are ready, which is why we're suggesting it be added at this time. These extensions will make the migration easier, especially for large organizations with complicated PKIs. As Erik Andersen mentioned, the extensions are currently working their way through X.509. Proposing this draft to LAMPS is not intended to duplicate that work, but it should make feedback to ITU-T easier (feedback such at the TLS discussion in London). Additionally, for these extensions to be used in other protocols like TLS or CMS, other (we believe small) extensions to those protocols may be needed, so having it eventually published as an RFC via LAMPS would give other WGs an IETF document as a starting point for their own extensions. Thanks, Daniel On 2018-05-02, 4:41 PM, "Spasm on behalf of Russ Housley" <spasm-bounces@ietf.org<mailto:spasm-bounces@ietf.org> on behalf of housley@vigilsec.com<mailto:housley@vigilsec.com>> wrote: Based on the discussion in London and the "Potential Topics for LAMPS Recharter" mail thread. We propose the attached charter text. Please review and comment. Russ & Tim = = = = = = = = = The PKIX and S/MIME Working Groups have been closed for some time. Some updates have been proposed to the X.509 certificate documents produced by the PKIX Working Group and the electronic mail security documents produced by the S/MIME Working Group. The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working Group is chartered to make updates where there is a known constituency interested in real deployment and there is at least one sufficiently well specified approach to the update so that the working group can sensibly evaluate whether to adopt a proposal. The LAMPS WG is now tackling these topics: 1. Specify a discovery mechanism for CAA records to replace the one described in RFC 6844. Implementation experience has demonstrated an ambiguity in the handling of CNAME and DNAME records during discovery in RFC 6844, and subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in that approach. 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. Unlike the previous hashing standards, the SHA-3 family of functions are the outcome of an open competition. They have a clear design rationale and have received a lot of public analysis, giving great confidence that the SHA-3 family of functions are secure. Also, since SHA-3 uses a very different construction from SHA-2, the SHA-3 family of functions offers an excellent alternative. In particular, SHAKE128/256 and SHAKE256/512 offer security and performance benefits. 3. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information, as a result revoking them pointless. 4. Specify the use of a pre-shared key (PSK) along with other key management techniques with supported by the Cryptographic Message Syntax (CMS) as a near-term mechanism to protect present day communication from the future invention of a large-scale quantum computer. The invention of a such a quantum computer would pose a serious challenge for the key management algorithms that are widely deployed, especially the key transport and key agreement algorithms used today with the CMS to protect S/MIME messages. 5. Specify the use of hash-based signatures with the Cryptographic Message Syntax (CMS). A hash-based signature uses small private and public keys, and it has low computational cost; however, the signature values are quite large. For this reason they will probably not be used for signing X.509 certificates or S/MIME messages, but they are secure even if a large-scale quantum computer is invented. These properties make hash-based signatures useful in some environments, such a the distribution of software updates. 6. Specifies a certificate extension that is carried in a self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate, to identify the next public key that will be used by the trust anchor. In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt any of these potential work items without rechartering. MILESTONES Mar 2018: Adopt a draft for rfc6844bis Apr 2018: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512 Apr 2018: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512 Jun 2018: Adopt a draft for short-lived certificate conventions Jun 2018: Adopt a draft for the CMS with PSK Jun 2018: Adopt a draft for hash-based signatures with the CMS Jun 2018: Adopt a draft for root key rollover certificate extension Jul 2018: rfc6844bis sent to IESG for standards track publication Aug 2018: Root key rollover certificate extension sent to IESG for informational publication Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for standards track publication Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for standards track publication Oct 2018: Short-lived certificate conventions sent to IESG for BCP publication Oct 2018: The CMS with PSK sent to IESG for standards track publication Dec 2018: Hash-based signatures with the CMS sent to IESG for standards track publication
- Re: [lamps] Potential Topics for LAMPS Recharter Russ Housley
- Re: [lamps] Draft LAMPS Recharter Erik Andersen
- [lamps] Potential Topics for LAMPS Recharter Russ Housley
- Re: [lamps] Potential Topics for LAMPS Recharter Tim Hollebeek
- Re: [lamps] Potential Topics for LAMPS Recharter Stephen Farrell
- Re: [lamps] Potential Topics for LAMPS Recharter Erik Andersen
- Re: [lamps] Potential Topics for LAMPS Recharter Phillip Hallam-Baker
- Re: [lamps] Potential Topics for LAMPS Recharter Panos Kampanakis (pkampana)
- Re: [lamps] Potential Topics for LAMPS Recharter Tim Hollebeek
- Re: [lamps] Potential Topics for LAMPS Recharter Russ Housley
- [lamps] Draft LAMPS Recharter Russ Housley
- Re: [lamps] Draft LAMPS Recharter Panos Kampanakis (pkampana)
- Re: [lamps] Draft LAMPS Recharter Russ Housley
- Re: [lamps] Draft LAMPS Recharter Ryan Sleevi
- Re: [lamps] Draft LAMPS Recharter Russ Housley
- Re: [lamps] Draft LAMPS Recharter Yoav Nir
- Re: [lamps] Draft LAMPS Recharter Ryan Sleevi
- Re: [lamps] Draft LAMPS Recharter Phillip Hallam-Baker
- Re: [lamps] Draft LAMPS Recharter Eric Rescorla
- Re: [lamps] Draft LAMPS Recharter Ryan Sleevi
- Re: [lamps] Draft LAMPS Recharter Ryan Sleevi
- Re: [lamps] Draft LAMPS Recharter Phillip Hallam-Baker
- Re: [lamps] Draft LAMPS Recharter Ryan Sleevi
- Re: [lamps] Draft LAMPS Recharter Stephen Farrell
- Re: [lamps] Draft LAMPS Recharter Tim Hollebeek
- Re: [lamps] Draft LAMPS Recharter Russ Housley
- Re: [lamps] Draft LAMPS Recharter Jim Schaad
- Re: [lamps] Draft LAMPS Recharter Salz, Rich
- Re: [lamps] Draft LAMPS Recharter Daniel Van Geest
- Re: [lamps] Draft LAMPS Recharter Russ Housley
- Re: [lamps] Draft LAMPS Recharter Daniel Van Geest
- Re: [lamps] Draft LAMPS Recharter Russ Housley
- Re: [lamps] Draft LAMPS Recharter Daniel Van Geest