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."¶

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

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.¶

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].¶

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.¶

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.¶

Author's Address