WG Review: Limited Additional Mechanisms for PKIX and SMIME (lamps)
The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2021-05-15. Limited Additional Mechanisms for PKIX and SMIME (lamps) --- Current status: Active WG Chairs: Russ Housley Tim Hollebeek Assigned Area Director: Roman Danyliw Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: sp...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/spasm Archive: https://mailarchive.ietf.org/arch/browse/spasm/ Group page: https://datatracker.ietf.org/group/lamps/ 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 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. 2. 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. 3. The Certificate Management Protocol (CMP) is specified in RFC 4210, and it offers a vast range of certificate management options. CMP is currently being used in many different industrial environments, but it needs to be tailored to the specific needs of such machine-to-machine scenarios and communication among PKI management entities. The LAMPS WG will develop a "lightweight" profile of CMP to more efficiently support of these environments and better facilitate interoperable implementation, while preserving cryptographic algorithm agility. In addition, necessary updates and clarifications to CMP will be specified in a separate document. This work will be coordinated with the LWIG WG. 4. Provide concrete guidance for implementers of email user agents to promote interoperability of end-to-end cryptographic protection of email messages. This may include guidance about the generation, interpretation, and handling of protected messages; management of the relevant certificates; documentation of how to avoid common failure modes; strategies for deployment in a mixed environment; as well as test vectors and examples that can be used by implementers and interoperability testing. The resulting robust consensus among email user agent implementers is expected to provide more usable and useful cryptographic security for email users. 5. Recent progress in the development of quantum computers pose a threat to widely deployed public key algorithms. As a result, there is a need to prepare for a day when cryptosystems such as RSA, Diffie-Hellman, ECDSA, ECDH, and EdDSA cannot be depended upon in the PKIX and S/MIME protocols. 5.a. The US National Institute of Standards and Technology (NIST) has a Post-Quantum Cryptography (PQC) effort to produce one or more quantum-resistant public-key cryptographic algorithm standards. The LAMPS WG will specify the use of these new PQC public key algorithms with the PKIX certificates and the Cryptographic Message Syntax (CMS). These specifications will use object identifiers for the new algorithms that are assigned by NIST. 5.b. NIST and other organizations are developing standards for post-quantum cryptographic (PQC) algorithms that that will be secure even if large-scale quantum computers are ever developed. However, a lengthy transition from today's public key algorithms to PQC public key algorithms is expected; time will be needed to gain full confidence in the new PQC public key algorithms. 5.b.i. The LAMPS WG will specify formats, identifiers, enrollment, and operational practices for "hybrid key establishment" that combines the shared secret
WG Review: Limited Additional Mechanisms for PKIX and SMIME (lamps)
The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2019-11-11. Limited Additional Mechanisms for PKIX and SMIME (lamps) --- Current status: Active WG Chairs: Russ Housley Tim Hollebeek Assigned Area Director: Roman Danyliw Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: sp...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/spasm Archive: https://mailarchive.ietf.org/arch/browse/spasm/ Group page: https://datatracker.ietf.org/group/lamps/ 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 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. 2. 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. 3. The Certificate Management Protocol (CMP) is specified in RFC 4210, and it offers a vast range of certificate management options. CMP is currently being used in many different industrial environments, but it needs to be tailored to the specific needs of some environments. The LAMPS WG will develop a "lightweight" profile of CMP to more efficiently support of these environments and better facilitate interoperable implementation, while preserving cryptographic algorithm agility. In addition, necessary updates and clarifications to CMP will be specified in a separate document. This work will be coordinated with the LWIG WG. In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WG. The LAMPS WG may produce clarifications where needed, but the LAMPS WG shall not adopt anything beyond clarifications without rechartering. Milestones: Nov 2019 - Adopt a draft for short-lived certificate conventions Dec 2019 - Adopt a draft for header protection conventions Dec 2019 - Adopt a draft for CMP updates Dec 2019 - Adopt a draft for Lightweight CMP profile Nov 2020 - Short-lived certificate conventions sent to IESG for BCP publication Nov 2020 - CMP updates sent to IESG for standards track publication Nov 2020 - Lightweight CMP profile sent to IESG for informational publication Mar 2021 - Header protection conventions sent to IESG for standards track publication ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Limited Additional Mechanisms for PKIX and SMIME (lamps)
The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2019-05-13. Limited Additional Mechanisms for PKIX and SMIME (lamps) --- Current status: Active WG Chairs: Russ Housley Tim Hollebeek Assigned Area Director: Roman Danyliw Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: sp...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/spasm Archive: https://mailarchive.ietf.org/arch/browse/spasm/ Group page: https://datatracker.ietf.org/group/lamps/ 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: Jun 2018 - Adopt a draft for short-lived certificate conventions Jun 2018 - Adopt a draft
WG Review: Limited Additional Mechanisms for PKIX and SMIME (lamps)
The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2018-06-06. Limited Additional Mechanisms for PKIX and SMIME (lamps) --- Current status: Active WG Chairs: Russ Housley Timothy Hollebeek Assigned Area Director: Eric Rescorla Security Area Directors: Eric Rescorla Benjamin Kaduk Mailing list: Address: sp...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/spasm Archive: https://mailarchive.ietf.org/arch/browse/spasm/ Group page: https://datatracker.ietf.org/group/lamps/ 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 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 might 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: 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
WG Review: Limited Additional Mechanisms for PKIX and SMIME (lamps)
The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2018-02-19. Limited Additional Mechanisms for PKIX and SMIME (lamps) --- Current status: Active WG Chairs: Russ HousleyAssigned Area Director: Eric Rescorla Security Area Directors: Kathleen Moriarty Eric Rescorla Mailing list: Address: sp...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/spasm Archive: https://mailarchive.ietf.org/arch/browse/spasm/ Group page: https://datatracker.ietf.org/group/lamps/ 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. Having completed the S/MIME 4.0 specifications and updates to support i18n email addresses in PKIX certificates, the LAMPS WG is now tackling these topics: 1. Specify a discovery mechanism for CAA records to replace the one described in RFC 6844. 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. RFC 6844 describes the mechanism by which CAA records relating to a domain are discovered. Implementation experience has demonstrated an ambiguity in the current processing of CNAME and DNAME records during discovery. Subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in the current approach. 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, which gives 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. In addition, the LAMPS Working Group may investigate other updates to the documents produced by the PKIX and S/MIME Working Groups, but the LAMPS Working Group shall not adopt any of these potential work items without rechartering. Milestones: Apr 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 Apr 2018 - rfc6844bis sent to IESG for standards track 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