idnits 2.17.00 (12 Aug 2021) /tmp/idnits19287/draft-dkg-openpgp-stateless-cli-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 28, 2019) is 936 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '--' is mentioned on line 311, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-openpgp-rfc4880bis-08 == Outdated reference: A later version (-01) exists of draft-bre-openpgp-samples-00 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 openpgp D. Gillmor 3 Internet-Draft ACLU 4 Intended status: Informational October 28, 2019 5 Expires: April 30, 2020 7 Stateless OpenPGP Command Line Interface 8 draft-dkg-openpgp-stateless-cli-00 10 Abstract 12 This document defines a generic stateless command-line interface for 13 dealing with OpenPGP messages, known as "sop". It aims for a 14 minimal, well-structured API for dealing with OpenPGP object 15 security. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 30, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Subcommands . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Version Information . . . . . . . . . . . . . . . . . . . 5 57 3.2. Generate a Secret Key . . . . . . . . . . . . . . . . . . 5 58 3.3. Convert a Secret Key to a Certificate . . . . . . . . . . 5 59 3.4. Create a Detached Signature . . . . . . . . . . . . . . . 5 60 3.5. Verify a Detached Signature . . . . . . . . . . . . . . . 5 61 3.6. Encrypt a Message . . . . . . . . . . . . . . . . . . . . 6 62 3.7. Decrypt a Message . . . . . . . . . . . . . . . . . . . . 7 63 3.8. Adding ASCII Armor . . . . . . . . . . . . . . . . . . . 8 64 3.9. Removing ASCII Armor . . . . . . . . . . . . . . . . . . 9 65 4. Input/Output Indirect Types . . . . . . . . . . . . . . . . . 9 66 4.1. CERT . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.2. KEY . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.3. CIPHERTEXT . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.4. SIGNATURE . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.5. SESSIONKEY . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.6. PASSWORD . . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.7. VERIFICATIONS . . . . . . . . . . . . . . . . . . . . . . 11 73 4.8. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 5. Failure modes . . . . . . . . . . . . . . . . . . . . . . . . 11 75 6. Guidance for Implementors . . . . . . . . . . . . . . . . . . 12 76 6.1. One OpenPGP Message At a Time . . . . . . . . . . . . . . 12 77 6.2. Simplified Subset of OpenPGP Message . . . . . . . . . . 12 78 6.3. Validate Signatures Only From Known Signers . . . . . . . 13 79 6.4. Detached Signatures . . . . . . . . . . . . . . . . . . . 13 80 6.5. Reliance on Supplied Certs and Keys . . . . . . . . . . . 13 81 7. Guidance for Consumers . . . . . . . . . . . . . . . . . . . 13 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 8.1. Signature Verification . . . . . . . . . . . . . . . . . 14 84 8.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 15 85 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 86 9.1. Object Security vs. Transport Security . . . . . . . . . 15 87 10. Document Considerations . . . . . . . . . . . . . . . . . . . 15 88 10.1. Document History . . . . . . . . . . . . . . . . . . . . 16 89 10.2. Future Work . . . . . . . . . . . . . . . . . . . . . . 16 90 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 93 12.2. Informative References . . . . . . . . . . . . . . . . . 17 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 Different OpenPGP implementations have many different requirements, 99 which typically break down in two main categories: key/certificate 100 management and object security. 102 The purpose of this document is to provide a "stateless" interface 103 that primarily handles the object security side of things, and 104 assumes that secret key management and certificate management will be 105 handled some other way. 107 This separation should make it easier to provide interoperability 108 testing for the object security work, and to allow implementations to 109 consume and produce new cryptographic primitives as needed. 111 This document defines a generic stateless command-line interface for 112 dealing with OpenPGP messages, known here by the placeholder "sop". 113 It aims for a minimal, well-structured API. 115 An OpenPGP implementation should not name its executable "sop" to 116 implement this specification, of course. It just needs to provide an 117 binary that conforms to this interface. 119 A "sop" implementation should leave no trace on the system, and its 120 behavior should not be affected by anything other than command-line 121 arguments and input. 123 Obviously, the user will need to manage their secret keys (and their 124 peers' certificates) somehow, but the goal of this interface is to 125 separate out that task from the task of interacting with OpenPGP 126 messages. 128 While this document identifies a command-line interface, the rough 129 outlines of this interface should also be amenable to relatively 130 straightforward library implementations in different languages. 132 1.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 1.2. Terminology 142 This document uses the term "key" to refer exclusively to OpenPGP 143 Transferable Secret Keys (see section 11.2 of [RFC4880]). 145 It uses the term "certificate" to refer to OpenPGP Transferable 146 Public Key (see section 11.1 of [RFC4880]). 148 "Stateless" in "Stateless OpenPGP" means avoiding secret key and 149 certificate state. The user is responsible for managing all OpenPGP 150 certificates and secret keys themselves, and passing them to "sop" as 151 needed. The user should also not be concerned that any state could 152 affect the underlying operations. 154 2. Examples 156 These examples show no error checking, but give a flavor of how "sop" 157 might be used in practice from a shell. 159 The key and certificate files described in them (e.g. "alice.sec") 160 could be for example those found in 161 [I-D.draft-bre-openpgp-samples-00]. 163 sop generate "Alice Lovelace " > alice.sec 164 sop convert < alice.sec > alice.pgp 166 sop sign --as=text alice.sec < announcement.txt > announcement.txt.asc 167 sop verify announcement.txt.asc alice.pgp < announcement.txt 169 sop encrypt --sign-with=alice.sec --as=mime bob.pgp < msg.eml > encrypted.asc 170 sop decrypt alice.sec < ciphertext.asc > cleartext.out 172 3. Subcommands 174 "sop" uses a subcommand interface, similar to those popularized by 175 systems like "git" and "svn". 177 If the user supplies a subcommand that "sop" does not implement, it 178 fails with a return code of 69. If a "sop" implementation does not 179 handle a supplied option for a given subcommand, it fails with a 180 return code of 37. 182 For all commands that have an "--armor|--no-armor" option, it 183 defaults to "--armor", meaning that any output OpenPGP material 184 should be ASCII-armored (section 6 of [I-D.ietf-openpgp-rfc4880bis]) 185 by default. 187 3.1. Version Information 189 sop version 191 o Standard Input: ignored 193 o Standard Output: version string 195 The version string emitted should contain the name of the "sop" 196 implementation, followed by a single space, followed by the version 197 number. 199 3.2. Generate a Secret Key 201 sop generate [--armor|--no-armor] [--] [USERID...] 203 o Standard Input: ignored 205 o Standard Output: "KEY" (Section 4.2) 207 Generate a single default OpenPGP certificate with zero or more User 208 IDs. 210 3.3. Convert a Secret Key to a Certificate 212 sop convert [--armor|--no-armor] 214 o Standard Input: "KEY" (Section 4.2) 216 o Standard Output: "CERT" (Section 4.1) 218 3.4. Create a Detached Signature 220 sop sign [--armor|--no-armor] 221 [--as={binary|text}] [--] KEY [KEY...] 223 o Standard Input: "DATA" (Section 4.8) 225 o Standard Output: "SIGNATURE" (Section 4.4) 227 "--as" defaults to "binary". If "--as=text" and the input "DATA" is 228 not valid "UTF-8", "sop sign" fails with a return code of 53. 230 3.5. Verify a Detached Signature 232 sop verify [--not-before=DATE] [--not-after=DATE] 233 [--] SIGNATURE CERT [CERT...] 235 o Standard Input: "DATA" (Section 4.8) 237 o Standard Output: "VERIFICATIONS" (Section 4.7) 239 "--not-before" and "--not-after" indicate that only signatures with 240 dates in a certain range should be considered as possibly valid. 242 "--not-before" defaults to the beginning of time. 244 "--not-after" defaults to "now". 246 "sop verify" only returns 0 if at least one of the supplied "CERT"s 247 made a valid signature in the range over the "DATA" supplied. 249 For details about the valid signatures, the user MUST inspect the 250 "VERIFICATIONS" output. 252 If no "CERT" is supplied, "sop verify" fails with a return code of 253 19. 255 If at least one "CERT" is supplied, but no valid signatures are 256 found, "sop verify" fails with a return code of 3. 258 See Section 8.1 for more details about signature verification. 260 3.6. Encrypt a Message 262 sop encrypt [--as={binary|text|mime}] 263 [--armor|--no-armor] 264 [--mode={any|communications|storage}] 265 [--with-password=PASSWORD...] 266 [--session-key=SESSIONKEY] 267 [--sign-with=KEY...] 268 [--] [CERT...] 270 o Standard Input: "DATA" (Section 4.8) 272 o Standard Output: "CIPHERTEXT" (Section 4.3) 274 "--as" defaults to "binary". 276 "--mode" defaults to "any", meaning any encryption-capable subkey may 277 be used. 279 "--with-password" enables symmetric encryption (and can be used 280 multiple times if multiple passwords are desired). If "sop encrypt" 281 encounters a "PASSWORD" which is not a valid "UTF-8" string, it fails 282 with a return code of 31. If "sop encrypt" sees trailing whitespace 283 at the end of a "PASSWORD", it will trim the trailing whitespace 284 before using the password. 286 "--session-key" permits the encryptor to select the symmetric 287 encryption algorithm and specific session key. 289 "--sign-with" enables signing by a secret key (and can be used 290 multiple times if multiple signatures are desired). 292 If "--as" is set to either "--text" or "--mime", then "--sign-with" 293 will sign as a canonical text document. In this case, if the input 294 "DATA" is not valid "UTF-8", "sop encrypt" fails with a return code 295 of 53. 297 The resulting "CIPHERTEXT" should be decryptable by the secret keys 298 corresponding to each identified "CERT". 300 If no "CERT" or "--with-password" options are present, "sop encrypt" 301 fails with a return code of 19. 303 3.7. Decrypt a Message 305 sop decrypt [--session-key-out=SESSIONKEY] 306 [--with-password=PASSWORD...] 307 [--verify-out=VERIFICATIONS 308 [--verify-with=CERT...] 309 [--verify-not-before=DATE] 310 [--verify-not-after=DATE] ] 311 [--] [KEY...] 313 o Standard Input: "CIPHERTEXT" (Section 4.3) 315 o Standard Output: "DATA" (Section 4.8) 317 "--session-key-out" can be used to learn the session key on 318 successful decryption. 320 If "sop decrypt" fails for any reason and the identified "SESSIONKEY" 321 file already exists in the filesystem, the file will be unlinked. 323 "--with-password" enables symmetric decryption (and can be used 324 multiple times if the user wants to try more password are tried). 326 If "sop decrypt" tries and fails to use a supplied "PASSWORD", and it 327 observes that there is trailing "UTF-8" whitespace at the end of the 328 "PASSWORD", it will retry with the trailing whitespace stripped. 330 "--verify-out" produces signature verification status to the 331 designated file. 333 "sop decrypt" does not fail (that is, the return code is not 334 modified) based on the results of signature verification. The caller 335 MUST check the returned "VERIFICATIONS" to confirm signature status. 336 An empty "VERIFICATIONS" output indicates that no valid signatures 337 were found. If "sop decrypt" itself fails for any reason, and the 338 identified "VERIFICATIONS" file already exists in the filesystem, the 339 file will be unlinked. 341 "--verify-with" identifies a certificate whose signatures would be 342 acceptable for signatures over this message. 344 If the caller is interested in signature verification, both "-- 345 verify-out" and at least one "--verify-with" must be supplied. If 346 only one of these arguments is supplied, "sop decrypt" fails with a 347 return code of 23. 349 "--verify-not-before" and "--verify-not-after" provide a date range 350 for acceptable signatures, by analogy with the options for "sop 351 verify". They should only be supplied when doing signature 352 verification. 354 See Section 8.1 for more details about signature verification. 356 If no "KEY" or "--with-password" options are present, "sop decrypt" 357 fails with a return code of 19. 359 If unable to decrypt, "sop decrypt" fails with a return code of 29. 361 "sop decrypt" only returns cleartext to Standard Output that was 362 successfully decrypted. 364 3.8. Adding ASCII Armor 366 sop armor [--label={sig|key|cert|message}] 368 o Standard Input: 8-bit, unarmored OpenPGP material ("SIGNATURE", 369 "CERT", "KEY", or "CIPHERTEXT") 371 o Standard Output: the same material with ASCII-armoring added 373 The user can choose to specify the label used in the header and tail 374 of the armoring. If the user does not specify, "sop" inspects the 375 input and chooses the label appropriately. If "sop" cannot select a 376 label on the basis of the input, it treats it as literal data, and 377 labels it as a "message". 379 3.9. Removing ASCII Armor 381 sop dearmor 383 o Standard Input: ASCII-armored OpenPGP material ("CIPHERTEXT", 384 "SIGNATURE", "CERT", or "KEY") 386 o Standard Output: the same material with ASCII-armoring removed 388 4. Input/Output Indirect Types 390 Some material is passed to "sop" indirectly, typically by referring 391 to a filename containing the data in question. This type of data may 392 also be passed to "sop" on Standard Input, or delivered by "sop" to 393 Standard Output. 395 If the filename for any indirect material used as input has the 396 special form "@ENV:xxx", then contents of environment variable "$xxx" 397 is used instead of looking in the filesystem. 399 If the filename for any indirect material used as either input or 400 output has the special form "@FD:nnn" where "nnn" is a decimal 401 integer, then the associated data is read from file descriptor "nnn". 403 If any input data does not meet the requirements described below, 404 "sop" will fail with a return code of 41. 406 4.1. CERT 408 One OpenPGP certificate (section 11.1 of 409 [I-D.ietf-openpgp-rfc4880bis]) aka "Transferable Public Key". May be 410 armored. 412 4.2. KEY 414 One OpenPGP Transferable Secret Key (section 11.2 of 415 [I-D.ietf-openpgp-rfc4880bis]). May be armored. 417 Secret key material should be in cleartext (that is, it should not be 418 locked with a password). If the secret key maerial is locked with a 419 password, "sop" may fail to use the key. 421 4.3. CIPHERTEXT 423 "sop" accepts only a restricted subset of the arbitrarily-nested 424 grammar allowed by the OpenPGP Messages definition (section 11.3 of 425 [I-D.ietf-openpgp-rfc4880bis]). 427 In particular, it accepts and generates only: 429 An OpenPGP message, consisting of a sequence of PKESKs (section 5.1 430 of [I-D.ietf-openpgp-rfc4880bis]) and SKESKs (section 5.3 of 431 [I-D.ietf-openpgp-rfc4880bis]), followed by one SEIPD (section 5.14 432 of [I-D.ietf-openpgp-rfc4880bis]). 434 The SEIPD can decrypt into one of two things: 436 o "Maybe Signed Data" (see below), or 438 o Compressed data packet that contains "Maybe Signed Data" 440 "Maybe Signed Data" is a sequence of: 442 o N (zero or more) one-pass signature packets, followed by 444 o zero or more signature packets, followed by 446 o one Literal data packet, followed by 448 o N signature packets (corresponding to the outer one-pass 449 signatures packets) 451 FIXME: does any tool do compression inside signing? Do we need to 452 handle that? 454 May be armored. 456 4.4. SIGNATURE 458 One or more OpenPGP Signature packets. May be armored. 460 4.5. SESSIONKEY 462 This documentation uses the GnuPG defacto "ASCII" representation: 464 "ALGONUM:HEXKEY" 466 where "ALGONUM" is the decimal value associated with the OpenPGP 467 Symmetric Key Algorithms (section 9.3 of 468 [I-D.ietf-openpgp-rfc4880bis]). 470 As input, "ALGONUM:" alone (with an empty "HEXKEY") means "user 471 specifies the algorithm, but the implementation chooses an arbitrary 472 key for the cipher." 474 Example AES256 session key: 476 9:FCA4BEAF687F48059CACC14FB019125CD57392BAB7037C707835925CBF9F7BCD 478 4.6. PASSWORD 480 This is expected to be a "UTF-8" string, but for "sop decrypt", any 481 bytestring that the user supplies will be accepted. Note the details 482 in "sop encrypt" and "sop decrypt" about trailing whitespace! 484 4.7. VERIFICATIONS 486 One line per successful signature verification. Each line has two 487 structured fields delimited by a single space, followed by arbitary 488 text to the end of the line. 490 o ISO-8601 UTC datestamp 492 o Fingerprint of primary key of signing certificate 494 o arbitrary text 496 Example: 498 2019-10-24T23:48:29Z C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 signed by dkg! 500 4.8. DATA 502 Cleartext, arbitrary data. This is either a bytestream or "UTF-8" 503 text. 505 It MUST only be "UTF-8" text in the case of input supplied to "sop 506 sign --as=text" or "encrypt --as={mime|text}". If "sop" receives 507 "DATA" containing non-"UTF-8" octets it will fail with return code 508 53. 510 5. Failure modes 512 When "sop" succeeds, it will return 0 and emit nothing to Standard 513 Error. When "sop" fails, it fails with a non-zero return code, and 514 emits one or more warning messages on Standard Error. Known return 515 codes include: 517 +--------+----------------------------------------------------------+ 518 | Return | Meaning | 519 +--------+----------------------------------------------------------+ 520 | 0 | Success | 521 | | | 522 | 3 | No acceptable signatures found ("sop verify") | 523 | | | 524 | 19 | Missing required argument | 525 | | | 526 | 23 | Incomplete verification instructions ("sop decrypt") | 527 | | | 528 | 29 | Unable to decrypt ("sop decrypt") | 529 | | | 530 | 31 | Non-"UTF-8" password ("sop encrypt") | 531 | | | 532 | 37 | Unsupported option | 533 | | | 534 | 41 | Invalid data type (no secret key where "KEY" expected, | 535 | | etc) | 536 | | | 537 | 53 | Non-text input where text expected | 538 | | | 539 | 69 | Unsupported subcommand | 540 +--------+----------------------------------------------------------+ 542 A "sop" implementation MAY return other error codes than those listed 543 above. 545 6. Guidance for Implementors 547 "sop" uses a few assumptions that implementers might want to 548 consider. 550 6.1. One OpenPGP Message At a Time 552 "sop" is intended to be a simple tool that operates on one OpenPGP 553 object at a time. It should be composable, if you want to use it to 554 deal with multiple OpenPGP objects 556 FIXME: discuss what this means for streaming. The stdio interface 557 doesn't necessarily imply streamed output. 559 6.2. Simplified Subset of OpenPGP Message 561 While the formal grammar for OpenPGP Message is arbitrarily 562 nestable,"sop" constrains itself to what it sees as a single "layer" 563 (see Section 4.3). 565 This is a deliberate choice, because it is what most consumers 566 expect, and runaway recursion is bad news. 568 Note that an implementation of "sop decrypt" MAY choose to handle 569 more complex structures, but if it does, it should document the other 570 structures it handles and why it chooses to do so. We can use such 571 documentation to improve future versions of this spec. 573 6.3. Validate Signatures Only From Known Signers 575 There are generally only a few signers who are relevant for a given 576 OpenPGP message. When verifying signatures, "sop" expects that the 577 caller can identify those relevant signers ahead of time. 579 6.4. Detached Signatures 581 "sop" deals with detached signatures as the baseline form of OpenPGP 582 signatures. 584 The main problem this avoids is the trickiness of handling a 585 signature that is mixed inline into the data that it is signing. 587 6.5. Reliance on Supplied Certs and Keys 589 A truly stateless implementation may find that it spends more time 590 validating the internal consistency of certificates and keys than it 591 does on the actual object security operations. 593 For performance reasons, an implementation may choose to ignore 594 validation on certificate and key material supplied to it. The 595 security implications are of doing so depend on how the certs and 596 keys are managed outside of "sop". 598 7. Guidance for Consumers 600 While "sop" is originally conceived of as an interface for 601 interoperability testing, it's conceivable that an application that 602 uses OpenPGP for object security would want to use it. 604 FIXME: more guidance for how to use such a tool safely and 605 efficiently goes here. 607 FIXME: if an encrypted OpenPGP message arrives without metadata, it 608 is difficult to know which signers to consider when decrypting. How 609 do we do this efficiently without invoking "sop decrypt" twice, once 610 without "--verify-*" and again with the expected identity material? 612 8. Security Considerations 614 The OpenPGP object security model is typically used for 615 confidentiality and authenticity purposes. 617 8.1. Signature Verification 619 In many contexts, an OpenPGP signature is verified, to prove the 620 origin and integrity of an underlying object. 622 When "sop" checks a signature (e.g. via "sop verify" or "sop decrypt 623 --verify-with", it should only consider it to be verified only if at 624 least all of these conditions are met: 626 o The signature must be made by a signing-capable public key that is 627 present in one of the supplied "CERT"s 629 o The "CERT" and signing subkey must have been created before or at 630 the signature time 632 o The "CERT" and signing subkey must not have been expired at the 633 signature time 635 o The "CERT" and signing subkey must not be revoked with a "hard" 636 revocation 638 o If the "CERT" or signing subkey is revoked with a "soft" 639 revocation, then the signature time must predate the revocation 641 o The signing subkey must be properly bound to the primary key, and 642 cross-signed 644 o The signature (and any dependent signature, such as the cross-sig 645 or subkey binding signatures) must be made with strong 646 cryptographic algorithms (e.g., not "MD5" or a 1024-bit "RSA" key) 648 Implementers should typically also consider other factors in addition 649 to the origin and authenticity, including application-specific 650 information. 652 For example, consider the application domain of checking software 653 updates. 655 If software package Foo version 13.3.2 was signed on 2019-10-04, and 656 the user receives a copy of Foo version 12.4.8 that was signed on 657 2019-10-16, it may be authentic and have a more recent signature 658 date. But it is not an upgrade (12.4.8 < 13.3.2), and therefore it 659 should not be applied automatically. 661 In such cases, it is critical that the application confirms that the 662 other information verified is _also_ protected by the relevant 663 OpenPGP signature. 665 Signature validity is a complex topic, and this documentation cannot 666 list all possible details. 668 8.2. Compression 670 The interface as currently specified does not allow for control of 671 compression. Compressing and encrypting data that may contain both 672 attacker-supplied material and sensitive material could leak 673 information about the sensitive material (see the CRIME attack). 675 Unless an application knows for sure that no attacker-supplied 676 material is present on the input, it should not compress during 677 encryption. 679 9. Privacy Considerations 681 Material produced by "sop encrypt" may be placed on untrusted machine 682 (e.g., sent through the public "SMTP" network). That material may 683 contain metadata that leaks associational information (e.g., 684 recipient identifiers in PKESK packets). FIXME: document things like 685 PURBs and "--hidden-recipient") 687 9.1. Object Security vs. Transport Security 689 OpenPGP offers an object security model, but says little to nothing 690 about how the secured objects get to the relevant parties. 692 When sending or receiving OpenPGP material, the implementer should 693 consider what privacy leakage is implicit with the transport. 695 10. Document Considerations 697 [ RFC Editor: please remove this section before publication ] 699 This document is currently edited as markdown. Minor editorial 700 changes can be suggested via merge requests at 701 https://gitlab.com/dkg/openpgp-stateless-cli or by e-mail to the 702 authors. Please direct all significant commentary to the public IETF 703 OpenPGP mailing list: openpgp@ietf.org 705 10.1. Document History 707 10.2. Future Work 709 o "split" subcommand (split a clearsigned message into a message and 710 a detached signature) (see Section 6.4 712 o certificate transformation into popular publication forms: 714 * WKD 716 * DANE OPENPGPKEY 718 * Autocrypt 720 o "sop encrypt" - specify compression? (see Section 8.2) 722 o "sop encrypt" - specify padding policy/mechanism? 724 o "sop decrypt" - how can it more safely handle zip bombs? 726 o "sop decrypt" - what should it do when encountering weakly- 727 encrypted (or unencrypted) input? 729 o "sop encrypt" - minimize metadata (e.g. "--throw-keyids")? 731 o handling secret keys that are locked with passwords? 733 o do we need an interface (for performance?) that says "don't 734 validate certificates internally, just accept whatever's given as 735 legit data"? (see Section 6.5) 737 11. Acknowledgements 739 This work was inspired by Justus Winter's 740 [OpenPGP-Interoperability-Test-Suite], and discussions with Justus. 741 Problems with this spec are not his fault. 743 12. References 745 12.1. Normative References 747 [I-D.ietf-openpgp-rfc4880bis] 748 Koch, W., carlson, b., Tse, R., Atkins, D., and D. 749 Gillmor, "OpenPGP Message Format", draft-ietf-openpgp- 750 rfc4880bis-08 (work in progress), September 2019. 752 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 753 Requirement Levels", BCP 14, RFC 2119, 754 DOI 10.17487/RFC2119, March 1997, 755 . 757 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 758 Thayer, "OpenPGP Message Format", RFC 4880, 759 DOI 10.17487/RFC4880, November 2007, 760 . 762 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 763 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 764 May 2017, . 766 12.2. Informative References 768 [I-D.draft-bre-openpgp-samples-00] 769 Einarsson, B., juga, j., and D. Gillmor, "OpenPGP Example 770 Keys and Certificates", draft-bre-openpgp-samples-00 (work 771 in progress), October 2019. 773 [OpenPGP-Interoperability-Test-Suite] 774 "OpenPGP Interoperability Test Suite", October 2019, 775 . 777 Author's Address 779 Daniel Kahn Gillmor 780 American Civil Liberties Union 781 125 Broad St. 782 New York, NY 10004 783 USA 785 Email: dkg@fifthhorseman.net