Network Working Group D. Huigens, Ed. Internet-Draft Proton AG Updates: 4880 (if approved) 26 June 2024 Intended status: Standards Track Expires: 28 December 2024 OpenPGP Signature Salt Notation draft-huigens-openpgp-signature-salt-notation-00 Abstract This document defines the "salt" Notation Name for OpenPGP version 4 signatures. This can be used to salt version 4 signatures in a backwards-compatible way. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://twisstle.gitlab.io/openpgp-signature-salt-notation/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-huigens-openpgp-signature- salt-notation/. Discussion of this document takes place on the OpenPGP Working Group mailing list (mailto:openpgp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/openpgp/. Subscribe at https://www.ietf.org/mailman/listinfo/openpgp/. Source for this draft and an issue tracker can be found at https://gitlab.com/twisstle/openpgp-signature-salt-notation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Huigens Expires 28 December 2024 [Page 1] Internet-Draft OpenPGP Signature Salt Notation June 2024 This Internet-Draft will expire on 28 December 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Notation Data Subpacket Type . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 8.2. Informative References . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The crypto refresh [crypto-refresh] of the OpenPGP standard [RFC4880] introduces version 6 signatures, which are salted. This has several benefits, such as preventing fault attacks against EdDSA signatures. This document introduces a "salt" Notation Name so that version 4 signatures can benefit from some of the same advantages in a backwards-compatible way. Note, however, that the notations are not hashed first in the signature, and thus this does not automatically benefit from _all_ benefits described in Section 13.2 of [crypto-refresh]. Therefore, this proposal is not intended to delay or remove the necessity for deploying version 6 keys and signatures. Huigens Expires 28 December 2024 [Page 2] Internet-Draft OpenPGP Signature Salt Notation June 2024 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Any implementation that adheres to the format and methods specified in this document is called a compliant application. Compliant applications are a subset of the broader set of OpenPGP applications described in [RFC4880] and the OpenPGP crypto refresh [crypto-refresh]. Any [RFC2119] keyword within this document applies to compliant applications only. 3. Motivation Salting signatures can prevent certain attacks, such as fault attacks against EdDSA [PSSLR17]. In version 6 signatures, a salt was added (see Section 5.2.3 and Section 13.2 of [crypto-refresh]). For version 4 signatures, some implementations (originating with Sequoia- PGP) add a signature notation to add a salt in a backwards-compatible manner. To comply with [crypto-refresh], implementations have created implementation-specific notation names under a domain they control (such as "salt@notations.sequoia-pgp.org"). However, this adds some overhead for each created signature, compared to a shorter notation name in the IETF namespace. Additionally, it adds to the distinguishability of OpenPGP artifacts, unless all implementations use the same notation name. For implementations that wish to disguise which implementation created any given artifact, it may be preferable to use only notations from the IETF namespace. 4. Notation Data Subpacket Type This document defines a new Notation Data Subpacket Type for use with OpenPGP, extending Table 7 of [crypto-refresh]. +===============+===========+================+ | Notation Name | Data Type | Allowed Values | +===============+===========+================+ | salt | binary | random data | +---------------+-----------+----------------+ Table 1: Signature Salt Notation registration This notation can be used to store a random salt in version 4 signatures (see section 5.2 of [crypto-refresh]). The length of the salt MUST match the "V6 signature salt size" value defined for the hash algorithm as specified in Table 23 of [crypto-refresh]. The "human-readable" flag MUST NOT be set for this notation name. Huigens Expires 28 December 2024 [Page 3] Internet-Draft OpenPGP Signature Salt Notation June 2024 5. Security Considerations Unlike the salt in version 6 signatures (as defined in Section 5.2.3 of [crypto-refresh]), which is hashed at the start before all other data, a salt in a Notation Data subpacket is hashed after the data to be signed (see Section 5.2.3.6 of [crypto-refresh]). Because of this, the salt notation may not prevent chosen prefix collision attacks like version 6 signatures do (see Section 13.2 of [crypto-refresh]). Therefore, this mechanism is not intended to replace or delay the deployment of version 6 signatures. It should only be used when the use of version 4 signatures is required (e.g. for compatibility reasons). 6. IANA Considerations IANA is requested to add the registration in Table 1 to the "OpenPGP Signature Notation Data Subpacket Types" registry, with a reference to this document in the "Reference" column. 7. Acknowledgements The idea and first implementation of a salt notation came from Sequoia-PGP. 8. References 8.1. Normative References [crypto-refresh] Wouters, P., Huigens, D., Winter, J., and N. Yutaka, "OpenPGP", January 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, . 8.2. Informative References Huigens Expires 28 December 2024 [Page 4] Internet-Draft OpenPGP Signature Salt Notation June 2024 [PSSLR17] Poddebniak, D., Somorovsky, J., Schinzel, S., Lochter, M., and P. Rösler, "Attacking Deterministic Signature Schemes using Fault Attacks", October 2017, . Author's Address Daniel Huigens (editor) Proton AG Route de la Galaise 32 CH-1228 Plan-les-Ouates Switzerland Email: d.huigens@protonmail.com Huigens Expires 28 December 2024 [Page 5]