[Sandbox-mailoutput] [Django development] Internal WG Review: Limited Additional Mechanisms for PKIX and SMIME (lamps)
IETF Secretariat <ietf-secretariat-reply@ietf.org> Thu, 24 October 2019 15:22 UTC
Return-Path: <ietf-secretariat-reply@ietf.org>
X-Original-To: sandbox-mailoutput@ietfa.amsl.com
Delivered-To: sandbox-mailoutput@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8541208FF for <sandbox-mailoutput@ietfa.amsl.com>; Thu, 24 Oct 2019 08:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.106
X-Spam-Level:
X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 fuMS8AAIKNQ4 for <sandbox-mailoutput@ietfa.amsl.com>; Thu, 24 Oct 2019 08:22:37 -0700 (PDT)
Received: from mailtest.ietf.org (unknown [4.31.198.57]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FCC31208DC for <sandbox-mailoutput@ietf.org>; Thu, 24 Oct 2019 08:22:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by sandbox.amsl.com (Postfix) with ESMTP id 01072605ACC for <sandbox-mailoutput@ietf.org>; Thu, 24 Oct 2019 08:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at mailtest.ietf.org
Received: from mailtest.ietf.org ([4.31.198.57]) by localhost (mailtest.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWavFj6jJaWO for <sandbox-mailoutput@ietf.org>; Thu, 24 Oct 2019 08:21:37 -0700 (PDT)
Received: from sandbox.amsl.com (localhost [IPv6:::1]) by sandbox.amsl.com (Postfix) with ESMTP id BD4AF6059CE for <sandbox-mailoutput@ietf.org>; Thu, 24 Oct 2019 08:21:36 -0700 (PDT)
Content-Type: multipart/mixed; boundary="===============5245017833894735560=="
MIME-Version: 1.0
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
To: sandbox-mailoutput@ietf.org
Message-ID: <157193049648.11380.14525705091675025596.idtracker@sandbox.amsl.com>
Date: Thu, 24 Oct 2019 08:21:36 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sandbox-mailoutput/QpoVsZAR_07y87lwSI5SvGJoVdI>
Subject: [Sandbox-mailoutput] [Django development] Internal WG Review: Limited Additional Mechanisms for PKIX and SMIME (lamps)
X-BeenThere: sandbox-mailoutput@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <sandbox-mailoutput.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sandbox-mailoutput>, <mailto:sandbox-mailoutput-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sandbox-mailoutput/>
List-Post: <mailto:sandbox-mailoutput@ietf.org>
List-Help: <mailto:sandbox-mailoutput-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sandbox-mailoutput>, <mailto:sandbox-mailoutput-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Oct 2019 15:22:38 -0000
The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody.
--- Begin Message ---A new charter for the Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the Security Area of the IETF is being considered. The draft charter for this WG is provided below for your review and comment. Review time is one week. The IETF Secretariat Limited Additional Mechanisms for PKIX and SMIME (lamps) ----------------------------------------------------------------------- Current status: Active WG Chairs: Russ Housley <housley@vigilsec.com> Tim Hollebeek <tim.hollebeek@digicert.com> Assigned Area Director: Roman Danyliw <rdd@cert.org> Security Area Directors: Benjamin Kaduk <kaduk@mit.edu> Roman Danyliw <rdd@cert.org> Mailing list: Address: spasm@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/spasm Archive: https://mailarchive.ietf.org/arch/browse/spasm/ Charter: https://datatracker.ietf.org/doc/charter-ietf-lamps/ 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 the approach used in RFC 6844. 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 short-lived certificates is unnecessary and 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 mechanism to protect present day communication from the future invention of a large-scale quantum computer. The invention of a large-scale quantum computer poses a serious challenge for the key management algorithms that are widely deployed today, 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). Hash-based signature use small private and public keys, and they have low computational cost; however, the signature values are quite large. For this reason they might not be used for signing X.509 certificates or S/MIME messages; however, since hash-based signature algorithms are secure even if a large-scale quantum computer is invented. The low computational cost for signature verification makes hash-based signatures attractive in the Internt of Things environments, and the quantum resistance makes them attractive for the distribution of software updates. 6. Specify 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. 7. Update the specification for the cryptographic protection of email headers -- both for signatures and encryption -- to improve the implementation situation with respect to privacy, security, usability and interoperability in cryptographically-protected electronic mail. Most current implementations of cryptographically-protected electronic mail protect only the body of the message, which leaves significant room for attacks against otherwise-protected messages. 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:--- End Message ---
- [Sandbox-mailoutput] [Django development] Interna… IETF Secretariat