From nobody Wed Jun 2 16:09:01 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D862E3A1F3F for ; Wed, 2 Jun 2021 16:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=7qRsqqFh; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=RtaPHJu+ 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 tE24QpaYQyUa for ; Wed, 2 Jun 2021 16:08:54 -0700 (PDT) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F423A1F3B for ; Wed, 2 Jun 2021 16:08:53 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1622675331; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : from; bh=hLnRG0cu0wZZs1I2cYbHMwDgQejwNtwG0QwNyD7sUTw=; b=7qRsqqFhxVwFvwNjY1OJ+mfKANwNUPrh31XJqSqJEJdD+B2gh6Pl9Y0YrwSbB9uyX0PhH Eyk7wyaF4sgqALpCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1622675331; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : from; bh=hLnRG0cu0wZZs1I2cYbHMwDgQejwNtwG0QwNyD7sUTw=; b=RtaPHJu+AcVy06nRcCBLmPOqZFYNk73odYZWIAWaza5F1XexbSHDIigH2lpZlx/NsaQeo L7M+OC/dfXgRdknyuBNbKjH9uhqDs05MD0HVHo4953Kw+gW2fGKUeuJfO9lFD10M6IP0QDi HdQLW01r9iSprx3hdlRt9eVGy9djDxgM8OugrbB88LA16q4I/OC1KhnA1zhDr0Cy2y9lTo1 JprFVHaaBj39F6l0kYlPeOlAAZBhXpwS1tn71A0zQDoF0U+xVcJpTTm9ZmlzTDlhvVaC/ej XzsN9TxoR0nIT49O0zhQtQg1jd6dvoZPvDY6RknuW9J0IhoieV3FUXXsIYMg== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 9EBCFF9A5 for ; Wed, 2 Jun 2021 19:08:51 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 670D220455; Wed, 2 Jun 2021 19:08:47 -0400 (EDT) From: Daniel Kahn Gillmor To: IETF OpenPGP WG Date: Wed, 2 Jun 2021 19:08:47 -0400 Message-Id: <20210602230847.3593022-1-dkg@fifthhorseman.net> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [openpgp] [RFC4880bis PATCH] WIP: bind wire format representations to specific pubkey algorithms X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2021 23:09:00 -0000 The OpenPGP standard is in a bit of a mess when it comes to wire formats for public key algorithms. There are not infrequent reports of interoperability problems (most recently https://dev.gnupg.org/T5464), and difficulties for implementers in understanding what is expected. I believe everything I've included in this changeset is in line with existing wire format practice. I am not trying to make substantive changes in wire format here, just to more accurately describe what existing implementations do. This changeset tries to clarify the situation by explicitly spelling out (and summarizing!) the wire formats for each public key algorithm, using the IANA registries for organized, tabular clarity. In particular, we are interested in wire formats for public keys, secret keys, signatures, and encryption frames. This proposed change uses the term "SBS" ("stripped bit string") to describe the weird form used by existing OpenPGP implementations for Ed25519 and Curve25519, where leading zeros are stripped but the "native" format is still used. This is an homage to gniibe's "SOS" proposal, while acknowledging that what Ed25519 and Curve25519 are doing isn't quite SOS. More significantly, the proposal explicitly binds specific elliptic curves to specific wire formats. So, if you're using NIST P-256, the wire format will always be the same going forward. If you're using EdDSA with Ed25519, it will also always use the same form. Most importantly, this clears the way for us to introduce simpler wire formats for new algorithms in the future (like "native 56-octet string" for Ed448). I believe this tight coupling is acceptable because anywhere these asymmetric elements (pubkey, seckey, signature, encryption) show up there is nothing of significance *after* them in any OpenPGP packet. So either you know the key and curve you're using (in which case you know how to parse the field) or you don't (in which case an ignorant parser can simply skip to the end of the packet directly, with no harm because it couldn't have dealt with the data anyway). I also believe this is acceptable because i don't know of anyone has actually tried to use alternate formats -- for EC points, scalars, etc -- with any curves other than the 25519 work. If that's wrong, I hope folks will speak up and show evidence. I am *not* confident in either my descriptions of the structures, or in how I've mapped them to different curves. I hope the WG will review the proposed changes, and help to resolve any lack of clarity or misrepresentations. --- crypto-refresh.md | 174 +++++++++++++++++++++++++++++----------------- 1 file changed, 112 insertions(+), 62 deletions(-) diff --git a/crypto-refresh.md b/crypto-refresh.md index 4b2d001..a47b5b8 100644 --- a/crypto-refresh.md +++ b/crypto-refresh.md @@ -411,6 +411,24 @@ Unused bits of an MPI MUST be zero. Also note that when an MPI is encrypted, the length refers to the plaintext MPI. It may be ill-formed in its ciphertext. +## Stripped Bit Strings + +A Stripped Bit String (SBS) is formed in the same way as a MPI, but it encodes a "native" bit string, not a big-endian integer, while stripping leading zero bits. + +The "length" of a bit string for this structure is calculated as the number of bits starting from the first 1 bit through the end of the string. + +On the wire, an SBS starts with a two-octet scalar that is the length, followed by a whole number of octets representing the bit string starting with the first non-zero octet. + +Like an MPI, the size on the wire of an SBS is ((SBS.length + 7) / 8) + 2 octets. + +Note that due to stripping of leading zeros, it is not possible with an SBS to encode a distinct string that has any leading zero bits. +That is, the raw 12-bit string `0b000000001111` would be encoded as an SBS in exactly the same way as the 6-bit string `0b001111` --- both would be `[00 04 0f]` on the wire. + +An implementation that encounters an SBS encoding in a context that demands an octet string with exactly N bits (e.g. for a native format that wants a fixed-length string) may find an SBS with fewer than N bits. +In this case, the implementation MUST create its internal representation of the value by prefixing zero bits to the wire representation, to bring the string to the expected size. + +This format is NOT RECOMMENDED for use when specifying future algorithms with OpenPGP, but it is necessary for handling pre-existing data. + ## Key IDs A Key ID is an eight-octet scalar that identifies a key. @@ -752,7 +770,7 @@ The body of this packet consists of: Algorithm-Specific Fields for ECDH encryption: - - MPI of an EC point representing an ephemeral public key. + - An EC point representing an ephemeral public key, encoded according to the curve in use. - a one-octet size, followed by a symmetric key encoded using the method described in {{ec-dh-algorithm-ecdh}}. @@ -1843,13 +1861,11 @@ The public key is this series of values: - a one-octet size of the following field; values 0 and 0xFF are reserved for future extensions, - - the octets representing a curve OID, defined in {{ecc-curve-oid}}; + - the octets representing a curve OID, defined in {{ecc-curves}}; -- a MPI of an EC point representing a public key. +- an EC point representing a public key, encoded according to the curve used. -The secret key is this single multiprecision integer: - -- MPI of an integer representing the secret key, which is a scalar of the public EC point. +The secret key is encoded according to the curve used, see {{ecc-curves}}. ### Algorithm-Specific Part for EdDSA Keys @@ -1859,13 +1875,11 @@ The public key is this series of values: - a one-octet size of the following field; values 0 and 0xFF are reserved for future extensions, - - the octets representing a curve OID, defined in {{ecc-curve-oid}}; + - the octets representing a curve OID, defined in {{ecc-curves}}; -- a MPI of an EC point representing a public key Q as described under EdDSA Point Format below. +- an EC point representing a public key Q, encoded according to the curve used. -The secret key is this single multiprecision integer: - -- MPI of an integer representing the secret key, which is a scalar of the public EC point. +The secret key is encoded according to the curve used, see {{ecc-curves}}. ### Algorithm-Specific Part for ECDH Keys @@ -1875,9 +1889,9 @@ The public key is this series of values: - a one-octet size of the following field; values 0 and 0xFF are reserved for future extensions, - - the octets representing a curve OID, defined in {{ecc-curve-oid}}; + - the octets representing a curve OID, defined in {{ecc-curves}}; -- a MPI of an EC point representing a public key; +- an EC point representing a public key, encoded according to the curve used; - a variable-length field containing KDF parameters, formatted as follows: @@ -1891,9 +1905,7 @@ The public key is this series of values: Observe that an ECDH public key is composed of the same sequence of fields that define an ECDSA key, plus the KDF parameters field. -The secret key is this single multiprecision integer: - -- MPI of an integer representing the secret key, which is a scalar of the public EC point. +The secret key is encoded according to the curve used, see {{ecc-curves}}. ## Compressed Data Packet (Tag 8) @@ -2509,18 +2521,18 @@ See {{notes-on-algorithms}} for more discussion of the algorithms. ## Public-Key Algorithms {#pubkey-algos} {: title="Public-key algorithm registry"} -ID | Algorithm ----:|-------------------------- - 1 | RSA (Encrypt or Sign) {{HAC}} - 2 | RSA Encrypt-Only {{HAC}} - 3 | RSA Sign-Only {{HAC}} - 16 | Elgamal (Encrypt-Only) {{ELGAMAL}} {{HAC}} - 17 | DSA (Digital Signature Algorithm) {{FIPS186}} {{HAC}} - 18 | ECDH public key algorithm - 19 | ECDSA public key algorithm {{FIPS186}} +ID | Algorithm | Public Key Format | Secret Key Format | Signature Format | Encryption Format +---:|--------------------------|---|---|---|--- + 1 | RSA (Encrypt or Sign) {{HAC}} | MPI(n), MPI(e) | MPI(d), MPI(p), MPI(q), MPI(u) | MPI(m\**d mod n) | MPI(m\**e mod n) + 2 | RSA Encrypt-Only {{HAC}} | MPI(n), MPI(e) | MPI(d), MPI(p), MPI(q), MPI(u) | N/A | MPI(m\**e mod n) + 3 | RSA Sign-Only {{HAC}} | MPI(n), MPI(e) | MPI(d), MPI(p), MPI(q), MPI(u) | MPI(m\**d mod n) | N/A + 16 | Elgamal (Encrypt-Only) {{ELGAMAL}} {{HAC}} | MPI(p), MPI(g), MPI(y) | MPI(x) | N/A | MPI(g\*\*k mod p), MPI (m * y\*\*k mod p) + 17 | DSA (Digital Signature Algorithm) {{FIPS186}} {{HAC}} | MPI(p), MPI(q), MPI(g), MPI(y) | MPI(x) | MPI(r), MPI(s) | N/A + 18 | ECDH public key algorithm | OID, Point (see {{ecc-curves}}) | see {{ecc-curves}} | N/A | Point (see {{ecc-curves}}) + 19 | ECDSA public key algorithm {{FIPS186}} | OID, Point (see {{ecc-curves}}) | see {{ecc-curves}} | see {{ecc-curves}} | N/A 20 | Reserved (formerly Elgamal Encrypt or Sign) 21 | Reserved for Diffie-Hellman (X9.42, as defined for IETF-S/MIME) - 22 | EdDSA {{RFC8032}} + 22 | EdDSA {{RFC8032}} | OID, Point(see {{ecc-curves}}) | see {{ecc-curves}} | see {{ecc-curves}} | N/A 23 | Reserved (AEDH) 24 | Reserved (AEDSA) 100 to 110 | Private/Experimental algorithm @@ -2532,10 +2544,9 @@ See {{rsa-notes}}. See {{reserved-notes}} for notes on Elgamal Encrypt or Sign (20), and X9.42 (21). Implementations MAY implement any other algorithm. - A compatible specification of ECDSA is given in {{RFC6090}} as "KT-I Signatures" and in {{SEC1}}; ECDH is defined in {{ec-dh-algorithm-ecdh}} this document. -## ECC Curve OID +## ECC Curve OID {#ecc-curves} The parameter curve OID is an array of octets that define a named curve. The table below specifies the exact sequence of bytes for each named curve referenced in this document: @@ -2549,6 +2560,15 @@ ASN.1 Object Identifier | OID len | Curve OID bytes in hexadecimal representatio 1.3.6.1.4.1.11591.15.1 | 9 | 2B 06 01 04 01 DA 47 0F 01 | Ed25519 1.3.6.1.4.1.3029.1.5.1 | 10 | 2B 06 01 04 01 97 55 01 05 01 | Curve25519 +{: title="ECC Curve wire formats"} +Curve name | ECDSA? | EdDSA? | ECDH? | EC Point Format | Secret Key Format | Signature Format +-----------|---|---|---|--------------|-------------|--- +NIST P-256 | Y | N | Y | Uncompressed | MPI(scalar) | MPI(r), MPI(s) +NIST P-384 | Y | N | Y | Uncompressed | MPI(scalar) | MPI(r), MPI(s) +NIST P-521 | Y | N | Y | Uncompressed | MPI(scalar) | MPI(r), MPI(s) +Ed25519 | N | Y | N | MPI-wrapped Native | SBS(native scalar) | SBS(r), SBS(s) +Curve25519 | N | N | Y | MPI-wrapped Native | SBS(native scalar) | N/A + The sequence of octets in the third column is the result of applying the Distinguished Encoding Rules (DER) to the ASN.1 Object Identifier with subsequent truncation. The truncation removes the two fields of encoded Object Identifier. The first omitted field is one octet representing the Object Identifier tag, and the second omitted field is the length of the Object Identifier body. @@ -2752,6 +2772,36 @@ ID | Algorithm | Reference \[ Note to RFC-Editor: Please remove the table above on publication. \] +This document requests IANA add the following wire format columns to the OpenPGP public-key algorithm registry: + +- Public Key Format +- Secret Key Format +- Signature Format +- Encryption Format + +And populate them with the values found in {{pubkey-algos}}. + +It also requests IANA to instantiate a new OpenPGP registry of Elliptic Curve Point Formats, with the columns: + +- Name +- Description +- Reference + +and populate these fields with the values found in {{ecc-point-representations}}. + +It also requests IANA to instantiate a new OpenPGP registry of Elliptic Curves, with the following columns: + +- Curve name +- OID +- ECDSA? +- EdDSA? +- ECDH? +- EC Point Format +- Secret Key Format +- Signature Format + +And populate these fields with the values found in {{ecc-curves}}. + ### Symmetric-Key Algorithms OpenPGP specifies a number of symmetric-key algorithms. @@ -3010,42 +3060,55 @@ This document references three named prime field curves, defined in {{FIPS186}} Further curve "Curve25519", defined in {{RFC7748}} is referenced for use with Ed25519 (EdDSA signing) and X25519 (encryption). The named curves are referenced as a sequence of bytes in this document, called throughout, curve OID. -{{ecc-curve-oid}} describes in detail how this sequence of bytes is formed. +{{ecc-curves}} describes in detail how this sequence of bytes is formed. + +## ECC Point Representations {#ecc-point-representations} + +This document defines wire formats for points on Elliptic Curves for use with ECDSA, ECDH, and EdDSA. + +Compression formats are associated with particular elliptic curves. +When a particular curve is in use, the point MUST be represented with the associated wire format. +A compliant application MUST NOT use an EC point format that is not associated with the curve used. + +The table below summarizes the registered forms. +Associations between the registered forms and specific curves are listed in {{ecc-curves}}. + +Even though the zero point, also called the point at infinity, may occur as a result of arithmetic operations on points of an elliptic curve, it SHALL NOT appear in data structures defined in this document. -## ECDSA and ECDH Conversion Primitives +{: title="ECC Point representations"} +Name | Description | Reference +---|--------------|------------- +Uncompressed | MPI(04 \|\| x \|\| y) | {{ecc-point-uncompressed}} +MPI-wrapped Native | MPI(40 \|\| LE(x)) | {{ecc-mpi-wrapped-native}} -This document defines the uncompressed point format for ECDSA and ECDH and a custom compression format for certain curves. -The point is encoded in the Multiprecision Integer (MPI) format. +### Uncompressed ECC Points {#ecc-point-uncompressed} + +An uncompressed point on an elliptic curve is encoded in the Multiprecision Integer (MPI) format. + +This format is used by NIST curves P-256, P-384, and P-521. For an uncompressed point the content of the MPI is: B = 04 || x || y -where x and y are coordinates of the point P = (x, y), each encoded in the big-endian format and zero-padded to the adjusted underlying field size. +where `x` and `y` are coordinates of the point `P = (x, y)`, each encoded in the big-endian format and zero-padded to the adjusted underlying field size. The adjusted underlying field size is the underlying field size that is rounded up to the nearest 8-bit boundary. This encoding is compatible with the definition given in {{SEC1}}. -For a custom compressed point the content of the MPI is: - - B = 40 || x - -where x is the x coordinate of the point P encoded to the rules defined for the specified curve. -This format is used for ECDH keys based on curves expressed in Montgomery form. +Since the coordinates are zero-padded to the adjusted underlying field size, the exact size of the MPI payload is 515 bits for "Curve P-256", 771 for "Curve P-384", and 1059 for "Curve P-521". -Therefore, the exact size of the MPI payload is 515 bits for "Curve P-256", 771 for "Curve P-384", 1059 for "Curve P-521", and 263 for Curve25519. +### MPI-wrapped Native ECC Points {#ecc-mpi-wrapped-native} -Even though the zero point, also called the point at infinity, may occur as a result of arithmetic operations on points of an elliptic curve, it SHALL NOT appear in data structures defined in this document. +Points on the elliptic curve 25519 are also represented in a Multiprecision Integer (MPI) format, but use a different prefix octet of 0x40, and use that curve's native little-endian format. -If other conversion methods are defined in the future, a compliant application MUST NOT use a new format when in doubt that any recipient can support it. -Consider, for example, that while both the public key and the per-recipient ECDH data structure, respectively defined in {{algorithm-specific-part-for-ecdh-keys}} and {{public-key-encrypted-session-key-packets-tag-1}}, contain an encoded point field, the format changes to the field in {{public-key-encrypted-session-key-packets-tag-1}} only affect a given recipient of a given message. +This format is: -## EdDSA Point Format + B = 40 || x -The EdDSA algorithm defines a specific point compression format. -To indicate the use of this compression format and to make sure that the key can be represented in the Multiprecision Integer (MPI) format the octet string specifying the point is prefixed with the octet 0x40. -This encoding is an extension of the encoding given in {{SEC1}} which uses 0x04 to indicate an uncompressed point. +where `x` is the x coordinate of the point `P`, zero-padded to the the field size in full octets, and encoded in little-endian form. +This encoding of `x` is compatible with the definition in section 2 of {{RFC8032}}. -For example, the length of a public key for the curve Ed25519 is 263 bit: 7 bit to represent the 0x40 prefix octet and 32 octets for the native value of the public key. +The exact size of the MPI payload is 263 for Curve25519 (ECDH) or Ed25519 (EdDSA): 7 bits to represent the 0x40 prefix octet and 32 octets for the native value of the public key. ## Key Derivation Function @@ -3082,7 +3145,7 @@ The KDF parameters are encoded as a concatenation of the following 5 variable-le - a one-octet size of the following field - - the octets representing a curve OID, defined in {{ecc-curve-oid}} + - the octets representing a curve OID, defined in {{ecc-curves}} - a one-octet public key algorithm ID defined in {{pubkey-algos}} @@ -3733,19 +3796,6 @@ An open problem can be recorded and tracked as [an issue](https://gitlab.com/ope \[Note to RFC-Editor: Please remove this section on publication.\] -# ECC Point compression flag bytes - -This specification introduces the new flag byte 0x40 to indicate the point compression format. -The value has been chosen so that the high bit is not cleared and thus to avoid accidental sign extension. -Two other values might also be interesting for other ECC specifications: - - Flag Description - ---- ----------- - 0x04 Standard flag for uncompressed format - 0x40 Native point format of the curve follows - 0x41 Only X coordinate follows. - 0x42 Only Y coordinate follows. - # Acknowledgements This memo also draws on much previous work from a number of other authors, including: Derek Atkins, Charles Breed, Dave Del Torto, Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben Laurie, Raph Levien, Colin Plumb, Will Price, David Shaw, William Stallings, Mark Weaver, and Philip R. -- 2.30.2 From nobody Thu Jun 3 23:43:04 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC723A2BC0 for ; Thu, 3 Jun 2021 23:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=S/h4f6xZ; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=Q5nzh2fj 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 VJqanNRLTv_l for ; Thu, 3 Jun 2021 23:42:57 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE54D3A2C1D for ; Thu, 3 Jun 2021 23:42:52 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1622788970; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=c6Fdd/T3hgXDJyr2I9k5vO5B0bywMYB/KSpPB6vGpco=; b=S/h4f6xZyQQh3+VlPvT+UxSaPWRO6HC/1IkR1b5s6AnJgEI1iHTSJ2ctq69KOt6V+7xVh 5SkObVYspW9R6/VAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1622788970; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=c6Fdd/T3hgXDJyr2I9k5vO5B0bywMYB/KSpPB6vGpco=; b=Q5nzh2fjuXiDkVJi072yCdMrdNuxzRzmzxN/7gbJF4xd8c0xkvgMmqhJyp1LoN+VODErO cmfKgIVqvSX6JMMO/zQEZUNGlPyCNK9ZZj5Laj/wgS7GUQA5krL3AoM03jXZTPbGkwUaJoD 2R/Hl94m6Uv7JV8xnrFGl+dJyWgs4wJBy2C7uB2/uS0AShPf0NZLf4RiRNO7cn5OFOf1/U8 DWWO3mQx7OSWuDGrHOrWKYOTwlszrUo3LJ39zKoLbJsOySyBLoiGF0y1UtsS4lMdB59A29m ZGjmF6YAIlGiOb3+XgAHqnoqx1ruAuiwjwQszUMjAoL0IwCAoZvy4CcHInCA== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id CD0EAF9A5 for ; Fri, 4 Jun 2021 02:42:50 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id B792720362; Fri, 4 Jun 2021 02:42:36 -0400 (EDT) From: Daniel Kahn Gillmor To: openpgp@ietf.org Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Fri, 04 Jun 2021 02:42:35 -0400 Message-ID: <87lf7q6sh0.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 06:43:02 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I've been reviewing the changes in draft-ietf-openpgp-crypto-refresh-03. I have concerns about most of the "v5" features currently incorporated. One of the reasons that we need to complete the crypto refresh for OpenPGP is that SHA1 is baked into the spec in the v4 fingerprint format. The v5 fingerprint uses SHA256, which resolves that problem. I have no problems with that part. But there are several other parts of the current draft that are specified as "v5" that have unclear (or even harmful) utility to me and don't seem to be part of any sort of cryptographic update. I list them below, with explanation, but i want to ask the WG for a sense of what folks think we should do about them (either individually or entirely). I see three fairly simple outcomes, but i welcome other suggestions. Possible Outcomes =2D---------------- a) WG consensus that all of these are appropriate: keep them as-is b) WG consensus that some of them are misfeatures, or otherwise inappropriate for the crypto-refresh: drop the unwanted parts from the specification of v5. c) WG consensus that some of them are misfeatures but due to pre-standardization deployment that produced existing artifacts, we can't claw them back: call the new OpenPGP version "v6" and just skip over v5 (like IP!) Note that for both (b) and (c) it's possible that the new version is basically just "v4 but with a SHA256 fingerprint instead of SHA1". I don't think that's necessarily a bad outcome! Specific v5 changes =2D------------------ Here are the outstanding parts of "v5" that differ from "v4" as of draft-ietf-openpgp-crypto-refresh-03 as far as i could tell. If you see others, please reply to this thread! 0) v5 public keys have a 4-octet scalar that is the size of the algorithm-specific fields.=20 1) v5 secret keys have the same scalar described in 0, plus two additional length fields: a one-octet scalar field for the length of the S2K metadata, and a four-octet scalar field one for the secret key material. 2) v5 certifications ("key signatures") hash a four-octet length of the subject key; v4 certifications hash instead a two-octet subject key length. 3) v5 data signatures over a literal data packet hash an additional 3 fields (or 6 zero octets for a cleartext or detached signature): - the one-octet content format, - the file name as a string (one octet length, followed by the file n= ame), - a four-octet number that indicates a date. 4) v5 data signatures hash the trailing length value as an eight-octet scalar, where v4 uses a four-octet scalar. Detailed Discussion =2D------------------ (0) and (1) appear to be duplicative of information already known by a parser: in particular the packet length itself. This appears to be an opportunity for error/inconsistency. What should implementations do if that value differs from the length remaining in the packet itself? =20=20=20=20 The textual justification for these changes appears to be: >> Note that the version 5 packet format adds two count values to help >> parsing packets with unknown S2K or public key algorithms. If the implementation doesn't know the public key or S2K algorithm, its only real recourse is to skip the packet anyway, so it's not clear what advantages these length fields offer. =2D---- (2) appears to prepare for keys larger than 65536 octets. This looks like post-quantum planning to me, but we are not including any PQ schemes in the specification, and it's not clear that this change on its own would be sufficient to support such a new scheme (especially because there doesn't seem to be any CFRG consensus on what PQ scheme to endorse yet). =2D---- (3) looks like it's trying to protect metadata that has not historically been protected by OpenPGP. However, it's also not clear how these fields will be used; presumably existing security-conscious implementations treat these fields as only-advisory anyway right now when trying to (for example) extract cleartext into the filesystem. But even if they're signed they might get ignored -- for example, just because the filename is cryptographically verified as "/etc/passwd" doesn't mean that an OpenPGP decryption utility should extract to that sensitive location. For tools that want to embed filesystem information into the signed data, it's of course possible to sign a tarball. In that approach, existing v4 signatures end up already covering the same metadata (and more). This change also has a consequence that it's not possible to transform an embedded/inline signature into a detached or cleartext signature, or vice versa, because detached or cleartext signatures have no place to store the content byte, filename, or timestamp. I've seen several use cases where translating a signature between inline/embedded format and detached or cleartext formats can be concretely useful. In one example, Debian's apt repository's Release, Release.gpg, and InRelease files contain the same data and should be able to share cryptographic signatures. Furthermore, it's not clear how these fields should be populated in the event that the signed "OpenPGP Message" is anything other than a "Literal Data Packet". For example, if the signature is made over a Compressed Data Packet, and that Compressed Data Packet contains a Literal Data Packet, how should those fields be populated when generating or verifying the signature. If we want a way to embed this kind of format/filesystem metadata into a signature, it would be trivial to define a subpacket including this information and include it in the Hashed Subpackets region of a signature, which would retain the ability to translate between detached/cleartext and inline/embedded signatures. =2D--- (4) appears to be an accomodation for signing data larger than 4GiB. v4 keys can of course currently still sign data larger than 4GiB. But as the current draft clarifies, v4 signatures can still be made over data larger than 4GiB because "The four-octet big-endian number is considered to be an unsigned integer modulo 2^32." It's not clear to me how this existing approach with v4 could be practically abused; why not just leave it? Conclusion =2D--------- Open questions for the WG: - Did I miss any other currently-adopted v5 changes? - Are there deployed systems/artifacts that use these fields that we need to worry about interoperability with? - Are there concrete reasons to keep any of the specific changes mentioned above, despite the counterindications described above? Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYLnLXAAKCRA+nXFzcd5W XFJdAQDa/Uk7TlofdqvjSnHa5d8qf+jPniAkwhw2JICBBl5jCwD/Uf9jOKWBbDgq yfDLsceq2h8pDg7ScaALMGsFE2RFbwk= =XtVO -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 4 10:12:19 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8508D3A19A3 for ; Fri, 4 Jun 2021 10:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com 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 32rDRHtwbAW0 for ; Fri, 4 Jun 2021 10:12:12 -0700 (PDT) Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7C43A199C for ; Fri, 4 Jun 2021 10:12:12 -0700 (PDT) Date: Fri, 04 Jun 2021 17:12:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1622826729; bh=9Z0L4cReCmtW/S5IHBVtTK6//s3dsccy5YBAsckkK5k=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=FnX/X/XFUwRWwtl6YT1UWSqT5qLLj3qy8QWMvjJvgjEzTb9/7qS+B+mu9ouVzIYWk uddgbg/qnhBDZI3/4kqWvht9tzH40I0ebQvEZf1Gq1XzNbXNmdeb3lmbYS4XGTZ9uu TFYnr8wZG1CTStwmLlgizra83FFHfuPeSAszWw3Q= To: Daniel Kahn Gillmor From: Daniel Huigens Cc: openpgp@ietf.org Reply-To: Daniel Huigens Message-ID: In-Reply-To: <87lf7q6sh0.fsf@fifthhorseman.net> References: <87lf7q6sh0.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 17:12:18 -0000 Just as one data point, we (OpenPGP.js) have fully implemented v5 from rfc4880bis, but always behind a flag with a stern warning that using it may break compatibility in the future. So we are in principle fine with doing so and changing the meaning of v5, indeed. As an alternative option, if the only goal is to fix SHA1 fingerprints, one thing that we have started doing internally at ProtonMail is giving keys "SHA256 fingerprints", defined simply as calculating the fingerprint but using SHA256 instead of SHA1. Obviously, for v5 keys this is equivalent, but if we want, we could introduce this as a concept for v4 keys in the crypto-refresh, and reserve v5 for a later spec. We might then also want an "Issuer SHA256 Fingerprint" subpacket, and allow it to be used for v4 keys as well. Similarly, we might want a version 2 of the KDF parameters, indicating that SHA256 is to be used for the fingerprint in the KDF. This would require modifying the public key, somewhat diminishing the benefits, but at least the primary key could remain the same. (I also don't think either of these are really security-critical, compared to the main use case of identifying keys, but I might be missing something.) Obviously, there's then additional work to be done in the public APIs of libraries, to expose SHA256 fingerprints, and making sure that people (and applications) use that instead of the SHA1 fingerprint wherever possible. Whether that is more or less work than transitioning from v4 to v5 keys, I'll leave up for debate :) (If we want to give them a more user friendly name, we could call them "long fingerprints", in contrast to "short key IDs" etc.) Best, Daniel From nobody Fri Jun 4 11:10:49 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87823A1BAB for ; Fri, 4 Jun 2021 11:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.5 X-Spam-Level: ** X-Spam-Status: No, score=2.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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 YgIgRa8RaOHf for ; Fri, 4 Jun 2021 11:10:43 -0700 (PDT) Received: from relay.sandelman.ca (minerva.sandelman.ca [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260973A1BA9 for ; Fri, 4 Jun 2021 11:10:43 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2607:f0b0:f:40::146]) by relay.sandelman.ca (Postfix) with ESMTPS id C85331F47A; Fri, 4 Jun 2021 18:10:37 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id A76E01A02B4; Fri, 4 Jun 2021 14:10:36 -0400 (EDT) From: Michael Richardson To: Daniel Kahn Gillmor , openpgp@ietf.org In-reply-to: <87lf7q6sh0.fsf@fifthhorseman.net> References: <87lf7q6sh0.fsf@fifthhorseman.net> Comments: In-reply-to Daniel Kahn Gillmor message dated "Fri, 04 Jun 2021 02:42:35 -0400." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Fri, 04 Jun 2021 14:10:36 -0400 Message-ID: <376548.1622830236@dooku> Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 18:10:48 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Daniel Kahn Gillmor wrote: > 2) v5 certifications ("key signatures") hash a four-octet length of > the subject key; v4 certifications hash instead a two-octet subject k= ey > length. > ----- > (2) appears to prepare for keys larger than 65536 octets. This looks > like post-quantum planning to me, but we are not including any PQ > schemes in the specification, and it's not clear that this change on > its own would be sufficient to support such a new scheme (especially > because there doesn't seem to be any CFRG consensus on what PQ scheme > to endorse yet). Sure, but wouldn't it help a v5 implementation to more intelligently skip such a thing? I don't know if we can support multiple signatures with different algorithms. > This change also has a consequence that it's not possible to transform > an embedded/inline signature into a detached or cleartext signature, = or > vice versa, because detached or cleartext signatures have no place to > store the content byte, filename, or timestamp. I've seen several use > cases where translating a signature between inline/embedded format and > detached or cleartext formats can be concretely useful. In one > example, Debian's apt repository's Release, Release.gpg, and InRelease > files contain the same data and should be able to share cryptographic > signatures. I think that your use case is reasonable. I also was thinking that with the Executive Order wrt Supply Chain security, and the number of systems which are debian based, and thus use Release.gpg = at the top, that having v5 sooner rather than later is probably important. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAmC6bJwACgkQlUzhVv38 QpAWLwf/ahJbV1MMUxY7s0Gn0e6TifdkJsGo7yWobjmwVSnewcF+SMuM741eDwv3 XYAgF+igHL4bIgN4AmpV9cF5UZWHmqcptQtf2iKkig5y0ujYyq3A0blcxFWhXuKR Z4X9D1X4cc3ZNH97OUisSgMvCoMFa1K5HIvRDrZqt0+RzAyeJiks/C1tHKHxvv8S 69nX54fSe4eYKbJ8JFCHT5jHmMqvo40BzZ4800XKrHXd9j+qi/Ge1Z7c+ly8CqOw BEnYL5JShb2fpYOc1341lYwL4oASptnHII7cCvfTpURprO/ZCMw2L0T1UH8wTFbh 5FGFTXk3rM/bR4TlWJMC2rDywL63JA== =fvHe -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 4 12:27:30 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860CB3A1DFA for ; Fri, 4 Jun 2021 12:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com 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 TES_Tcwyg_EH for ; Fri, 4 Jun 2021 12:27:22 -0700 (PDT) Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7E7B3A1DFB for ; Fri, 4 Jun 2021 12:27:20 -0700 (PDT) Date: Fri, 04 Jun 2021 19:27:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1622834837; bh=Pl/GK8Ov31rTRCqw5mqryuhIkbc1sc4J+xd1Fg9SaXU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=OtA7vw9lWVFXLkZaz4ew4l2adoRS/nHqW/WUGTKMh7/icUxZIEFhZ//AE4ox7kwMc VFvyJ1tIiBjNS/1+t0wDAGFFv3bcnEDOw4q4yBMhsUlOOHqMToMpm8ZaVgdH3TdCmT Y0yNyk10koTtFTX1PNAAa7agpuGcsjm+Q+bOpiJ4= To: Daniel Kahn Gillmor From: Daniel Huigens Cc: IETF OpenPGP WG Reply-To: Daniel Huigens Message-ID: In-Reply-To: <20210602230847.3593022-1-dkg@fifthhorseman.net> References: <20210602230847.3593022-1-dkg@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] WIP: bind wire format representations to specific pubkey algorithms X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 19:27:28 -0000 I'll be a bit contrarian here and say that, while I'm of course fine with binding the wire format to the public key algorithm, I'd prefer not to bind the wire format to the curve. Especially when it comes to Curve25519 and Curve448, they are specified together so often (see RFC7748, RFC8032, RFC8422, RFC8031, etc) that to me it seems strange to specify them in a different way in OpenPGP, especially given that this crypto-refresh will officially be the first place for both curves to appear. Of course, Curve25519 has been around in implementations for much longer, but still, from the perspective of the spec it seems strange. (Probably I should've brought up this concern sooner, when SOS was being discussed etc, but this patch made me realize the above.) For what it's worth, I fully agree that the current situation with Curve25519 is non-ideal and confusing, and that a simple byte string would be better. However, we'll likely be stuck with it forever, and I'm not sure if specifying a different wire format for Curve448 makes things any simpler. That being said, I don't think anything in this patch so far is really "incorrect", and if everyone else feels that it makes things clearer, (and, thanks dkg, indeed, for trying to make things clearer!) I'm OK with specifying things that way, just perhaps with the exception of the language saying that future algorithms should use a different encoding (even though I do agree with that as written, but it seems like a note for the future editors, not a note for current implementers.) Once we do specify a new public key algorithm (e.g. post-quantum), as opposed to just a new curve (my expectation is that adding post-quantum algorithms will be the next "crypto refresh", and that we will never need a new curve after Curve448), I fully agree that we definitely shouldn't do this byte-string-in-MPI thing again. When we do so, we could specify a new octet string type, or something else. But I'm not sure that between Curve25519 and Curve448 is the correct place to "draw the line in the sand". Best, Daniel From nobody Sat Jun 5 04:21:10 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4872E3A1F6D for ; Sat, 5 Jun 2021 04:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 ezrLinVxp6_w for ; Sat, 5 Jun 2021 04:21:04 -0700 (PDT) Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [180.189.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58273A1F6A for ; Sat, 5 Jun 2021 04:21:03 -0700 (PDT) Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2171.outbound.protection.outlook.com [104.47.71.171]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-89-jnXGeFGJOOGk55LA2qnl0w-1; Sat, 05 Jun 2021 21:20:54 +1000 X-MC-Unique: jnXGeFGJOOGk55LA2qnl0w-1 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com (2603:10c6:10:10b::10) by SYCPR01MB4272.ausprd01.prod.outlook.com (2603:10c6:10:41::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.24; Sat, 5 Jun 2021 11:20:49 +0000 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::9965:92dd:f5b:87a7]) by SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::9965:92dd:f5b:87a7%6]) with mapi id 15.20.4195.026; Sat, 5 Jun 2021 11:20:49 +0000 From: Peter Gutmann To: Daniel Kahn Gillmor , Daniel Huigens CC: "openpgp@ietf.org" Thread-Topic: [openpgp] v5 in the crypto-refresh draft Thread-Index: AQHXWQzuzdssG/TtVk6GhEyMb/dWfKsEF2UAgAEv9ww= Date: Sat, 5 Jun 2021 11:20:48 +0000 Message-ID: References: <87lf7q6sh0.fsf@fifthhorseman.net>, In-Reply-To: Accept-Language: en-NZ, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [14.1.76.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2f70a140-5408-4e42-723c-08d92813f8a7 x-ms-traffictypediagnostic: SYCPR01MB4272: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: NRD+9KVjZmixc+sHv9Q1EuDV3B/UCzLMv76XngUVkHczdPLfE9KMTIPZ16MmZnUyFlycQgkve3DSl5tx9AMG4wDahEO+4XnMwk9XYTmTpX8MKotBcpJOGD6ui0oGKO4yQLVGf6GQXqRiMiF9m/gE5wdJFyDtctdh3U1Mm6ujFnIkcFGEzm1rcjqfiiVisCSr+8vaaSzmxuJHGhBUMt6HJxGhBHAySODzzSzweWAJa/2GzyNXwY5Us0DXKvbKhWt1snlesAG7trkAtuu2glclc15CDFeooPgtM6+DtICAcVt6bVbOFV+kgcTDGkDbWjNYU0rIp0TCy3EjRrtzBIaLeHX7IrN54yO06IZwG/xsPvgldS+tLncGDhASQ3WlVsy3jm99AXPB6X1/a7yHi24SXqwCYNwk+KGBsPvhagpI2K/AtoYi/0gY8ajBsTDlx0fOVvA8h7Gdcs682OezP/I/qc9bWqj9By4T8NgRKYnsf5c/oTJG4HVstSxh/0OkpdaQStGO+8ugX3ep/k3SmalZRVJQoxMnPNTLnqQ7qp2iY7oDBrnsar4Yxyj8ktShAOTQ6QCSvwc5EQcbZzV80502V+lIvdsfr/MrzCRTtLZUIdk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6251.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(136003)(346002)(39860400002)(366004)(9686003)(26005)(7696005)(55016002)(86362001)(33656002)(4326008)(52536014)(478600001)(76116006)(38100700002)(66446008)(66476007)(64756008)(66556008)(2906002)(66946007)(71200400001)(6506007)(5660300002)(316002)(122000001)(786003)(186003)(110136005)(4744005)(8676002)(8936002); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?6HWC6tguhw9mqemgNl/YUoX1xppWcNLSG5gPR481LIe+mDj7k7PsiwnMpa?= =?iso-8859-1?Q?z5vLG1tSe0rYGwaHenZAE4SeITcfPHA0+er+Pa9yu7SnQq4cpQa4OcIf8r?= =?iso-8859-1?Q?b6XfI3iCY+atVeWWFVi3v1SKsGHMnfrmEyXcc8TvD6GzBZ5uSNH0q2fVQA?= =?iso-8859-1?Q?CI373ANfob7K4JA15Qkc0OxCRMYVrrV7Vgp0kVUfbjRtsp7Xw1xahnUtO0?= =?iso-8859-1?Q?l5IbtXkE7L/NRMZRBmT8GrfoBubgQ3wzAQjA3/IP5Ysdl5bN7RoLeHbTQP?= =?iso-8859-1?Q?ERyLVhbRqGVHlWv2BMk4pacq0p6mWDrkGQ0FztbwqCxSr0QbQlWx/6pMAJ?= =?iso-8859-1?Q?dZT+mX+b8hibVnVAwcMEKoE6z1ZcSVakDYnSaC9FNg8c9jfbKAyhnDcayH?= =?iso-8859-1?Q?bsaRgCCdzcSj+cz3bAa6HvyTdDBerBaP3i1DP5ykljp1bRWtidvtsc/JyS?= =?iso-8859-1?Q?cg7kkYTy4wrEAL7wY3fnzfyhqnNLkkm8h03c89tojWgd5eWgcHxi4uWXbV?= =?iso-8859-1?Q?6GXUt/I43XtRM9PzKbEEn/mGA+tVTSffrLHtAc0va3He+lLaA/TJE/WlF/?= =?iso-8859-1?Q?KvScNMNySlP0JFs0AQHbROLNJtQ6OsFDbijDGjGhtz7laAKpS2fusP8851?= =?iso-8859-1?Q?mO1HD1PwKuDV8dt4zxzDhk9b/M5BfjHh2xqzGIxhYuo6J5s4bZzQmcASH1?= =?iso-8859-1?Q?WZ1kybKZre8H9DV3GaJOiMvq9EbqJjfMeaVBKZ+O7TDRmgQwYQ7BA7HnwU?= =?iso-8859-1?Q?zLxdR1YWe2Bf7q6HnnTyPzF+OeHlvjoTrqVKpWtLyplbXECdKqcVFvfmHo?= =?iso-8859-1?Q?9GvBdzLohYMvcYnnii0i/bYMd0OEqszK+L+uZbqzvP2Hj2oarE/SlJGcuB?= =?iso-8859-1?Q?6dK3T3m1/KfREaVlWUY5O02/gRSGuW3YbSjvve4cTajHrgEjCy1Eadk7Cb?= =?iso-8859-1?Q?14UDbDDTMsBfB5bzv7oNuqOIu8TCg9YsIkAP3CASrfIIOLUpooRwPMAI0v?= =?iso-8859-1?Q?kJDmB59UeLp/r92BCqjcbQJERJXtOk64qgZjKAN3QhLuAIjVF4Lp3EAlZO?= =?iso-8859-1?Q?tzrLWGAqYfO9fs3sbCazRC1EFO1VCmDg9AFyESDbRawtOsMAIL+fzYm/kA?= =?iso-8859-1?Q?dNXe3FLqt6Ean2GuS8ZLrYVPST7uuUa0ubz1viCrUrupbMMVOAKbelS8AO?= =?iso-8859-1?Q?ffUhRcBLnfMr5nKd7VgLjjR9q113ANn/xQMx8UJNbD9fPNRx34VZQS1QXI?= =?iso-8859-1?Q?T2pmBnW124ZqZ6mGTpBloyWZ3UC8o186kS7rjpLB937TYhtxdSfwmdNCUY?= =?iso-8859-1?Q?NEXLtVBoO1OQzZogLD5avYBoAmEFQxB5E7ARykKLnsmwJVE=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6251.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f70a140-5408-4e42-723c-08d92813f8a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2021 11:20:48.0842 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qI2kP7T5x0uBXvZ6nRv6LhByLqtV3Sxc0odhxlRTUGRgQL753Fb7Ykg3RPUS2OTzzzAEQ46SXweVkdRjnOsx3O449EElF5Ccp84EtYcp/cE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYCPR01MB4272 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cs.auckland.ac.nz Content-Language: en-NZ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2021 11:21:08 -0000 Daniel Huigens writes:=0A=0A>= As an alternative option, if the only goal is to fix SHA1 fingerprints,=0A= =0AThe first thing to do when "fixing" SHA1 fingerprints, meaning breaking = all=0Aexisting fingerprints on the planet, is to define what properties the= y need to=0Ahave. I can't think of anything for which SHA-256 is OK but SH= A-1 isn't, so=0Abefore arbitrarily throwing SHA-256 in there we'd need to d= efine what's needed=0Afor a fingerprint algorithm to see why -1 doesn't mee= t the requirements, and=0Awhether -256 does.=0A=0ATo pre-empt the inevitabl= e response, collision-resistance isn't a property=0Athat I can see is neede= d, given that X.509 and S/MIME have been using static=0Atext strings as IDs= since before PGP existed without anyone finding=0Avulnerabilities with the= m. A fingerprint algorithm is just a way of mapping a=0Akey to a fixed-len= gth identifier, for which almost anything will do.=0A=0APeter.=0A From nobody Sat Jun 5 05:22:58 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA083A2132 for ; Sat, 5 Jun 2021 05:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 1rfIR7d71gOg for ; Sat, 5 Jun 2021 05:22:52 -0700 (PDT) Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [180.189.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840A93A2131 for ; Sat, 5 Jun 2021 05:22:50 -0700 (PDT) Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2168.outbound.protection.outlook.com [104.47.71.168]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-103--uZMaKiANFeL3NIT_9casw-1; Sat, 05 Jun 2021 22:22:42 +1000 X-MC-Unique: -uZMaKiANFeL3NIT_9casw-1 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com (2603:10c6:10:10b::10) by SY3PR01MB1404.ausprd01.prod.outlook.com (2603:10c6:0:15::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.24; Sat, 5 Jun 2021 12:22:39 +0000 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::9965:92dd:f5b:87a7]) by SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::9965:92dd:f5b:87a7%6]) with mapi id 15.20.4195.026; Sat, 5 Jun 2021 12:22:39 +0000 From: Peter Gutmann To: Daniel Kahn Gillmor , "openpgp@ietf.org" Thread-Topic: [openpgp] v5 in the crypto-refresh draft Thread-Index: AQHXWQzuzdssG/TtVk6GhEyMb/dWfKsFWKD1 Date: Sat, 5 Jun 2021 12:22:38 +0000 Message-ID: References: <87lf7q6sh0.fsf@fifthhorseman.net> In-Reply-To: <87lf7q6sh0.fsf@fifthhorseman.net> Accept-Language: en-NZ, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [14.1.76.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 55a0d2d8-6a29-4827-b747-08d9281c9bf4 x-ms-traffictypediagnostic: SY3PR01MB1404: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: +26yI6GICaoe3ChoXHV6LSfNv9OiDqVp37eWeoHZrufnr6LZg72OyZHK6OsDROWLFicORh7wJnCf6iLJPSW2P6/GvPrMzYsUJs9tSsrL7ryDWG8a1mT6R3fXW3gO4VjgEgrkXn4BwKVZzZQ+8moHO9t69dCTNJKNwMKoicycbtjP/EG9mDJKIGO9x6MqBse1lPX+xGUWakpKsCtVv6D8P6Y0anfB5iWgCSqZSQbC0YSZ3W3MTucgxb4m4CMg+6iLRyPqDYKPE8xC+PCVW22inwpAKevW8vQ5Am70R1hAZa2d5l1PEpCF28QwlMNEuuvbFBtdUSKo1k1dtSLQPtv3DxWgEhaoVzkD1EIRxUXiLA5P4hrdS2nr81nH2yxSM5S5CnmItWrd1g+aJCt2hl4zQdXYACqjqexhkBz612tUHpjk6f055Z8vRiUmqOqNtqfvYzOGc5JCkK3+NERC3WRXW92Ec2vy4zVewV25PqBEUMZUVw443puF4wLBPtw6y7q1Zyd+AECr7U+74CZmEtB1/j2OCd8PZs02DdcAUKNWrP6J52MqYLVbXRNEdXi77XvxZvIRmXfrC1v0OxqnTP14eCoFoa+oLXo+b+tNZW4D8qg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6251.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(366004)(39860400002)(376002)(396003)(86362001)(71200400001)(33656002)(110136005)(478600001)(6506007)(66446008)(66476007)(5660300002)(66556008)(316002)(786003)(8936002)(2906002)(52536014)(66946007)(55016002)(38100700002)(122000001)(26005)(7696005)(8676002)(186003)(4744005)(76116006)(9686003)(64756008); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?SoxUXn04+U2tbZKyK9p3qMubnqV/9jAPc1UTAUa/d7ZHBWRRckpMlBZajQ?= =?iso-8859-1?Q?LqcR15Jsa1QsILuy2VCZQqy0PA5XHKzJwIahHVk1Om5OrEXqz2ii4JxxnR?= =?iso-8859-1?Q?WiAFvv2Aa15fT56snGUl+FsCaif96Zr+1clnqS4JKLUKpZaexXspxTRoR9?= =?iso-8859-1?Q?Z1nPC3gn+5vSIhQurirItzKC1s3vuVd5EasOm5vPpOVSNNlCqKt7Uc41XO?= =?iso-8859-1?Q?7121Eg30bibo5vHAArXdeusai44pEW+88j7HINfl5ewTSCJs23IJJT1QhP?= =?iso-8859-1?Q?//1jofKAY1ez2UBzBOr7d5tIfc0LdAm8iiR1MdavEAFT6Sg/uXi5jdlSE/?= =?iso-8859-1?Q?qUKKvMAsgRFamp65BV+r+msCMvo4oMrUvna2FYZd30T8jHJ5YSo7qRl0yZ?= =?iso-8859-1?Q?Fla/2OyL4EAa+0fYJDsPBq6FCFmr6gPitPk9VdfZtDRBmvFS9IbugerNTh?= =?iso-8859-1?Q?MF/OJl91nEhp7ZVm9WlRLg3SW/XK7n7UHUVPw+3c4Erpc87Xc8SAXz9+sr?= =?iso-8859-1?Q?Sm0LTYaU47rRTcpmdysCK8vONyKcIvweUgaR0JIU1UZClWucksLaC0uC7Z?= =?iso-8859-1?Q?lHU99qquu+Zlv6KivF65ol5LL14r9OcXV6t4b4Gqs5zgTOTvTNLulB5IRR?= =?iso-8859-1?Q?Ipb6ohMX7Eo6U2weDHHVYVpXTzO7Ko7ScpiWK8nvpViBbUMJzBofOhlaet?= =?iso-8859-1?Q?bGatlCXGGdszwU1pYA2cS9J9LTRQ4SdHgVqAoPBoxdYHDYGVRCcZrB/W4u?= =?iso-8859-1?Q?WNYnedfmjmpLMECm/aXpYgJnYCQd0OGv3B8rF7yGaa75uxVKz42delo/uI?= =?iso-8859-1?Q?lBJpBYzAZNdqKRMRuMYalbTpMtKI9K9mQ3kMN4VbowtrJleNRu/CX3rXNm?= =?iso-8859-1?Q?s9uW9YQKJTDtJuDRLrUN87tlrdJ6p6ZvUsNLjbSGYwzybG7or2sX7nHyBA?= =?iso-8859-1?Q?kERkAZIA/3X1kkmD0KEK4kgbHD5QspAlLc0ALp2RulsstsNaMqcdt6WtHy?= =?iso-8859-1?Q?SoLqgC36mgROkoDpFvsPlTKbMyzP25rtcDrRubWoHK/Md2OXn6aRU7/X5f?= =?iso-8859-1?Q?zgbhTFCBgATVHJgAgKZBkpScv8vBuR73ymLTyPrJALgQ8WIKUL7IdJaOW0?= =?iso-8859-1?Q?YttxigMzrHSLAxPMNTJb8vypsDjBqgoBb3K3UVy7KX0YOVCJijVA9aaQtG?= =?iso-8859-1?Q?84/283QDnoX7xzt3QyrTF9ugT+6b4AyxG+0xWoi20Hz2BwG+7bUO7UHaav?= =?iso-8859-1?Q?Gj8yidBKFwiocJlpmY9GUa1yVOlEb1X4qqCak/cf74jMVuQMQ95utkgC05?= =?iso-8859-1?Q?AascttOeot5H3skMgbUt1gyjVSrdU7OJkk3Yj306WR7G36s=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6251.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 55a0d2d8-6a29-4827-b747-08d9281c9bf4 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2021 12:22:38.8256 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4oAXB+v4nD0Dal1KAWr9DuDJkfKHJwkchrtUcEIpePkTX1n/mkKH8HJ2tZMzmqZU45zLhOciHZctigJgghwDDuXtkIs+lxFR58t2z2WVqQU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY3PR01MB1404 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cs.auckland.ac.nz Content-Language: en-NZ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2021 12:22:56 -0000 Daniel Kahn Gillmor writes:=0A=0A>Specific v5 chang= es=0A=0AAnother thing I'd like to see changed in v5 is the incredibly annoy= ing way=0AOpenPGP handles its PRF. For every PRF use on the planet except = OpenPGP, you=0Aspecify the number of iterations of the PRF to be applied. = For OpenPGP you=0Aspecify the number of bytes to output and then have to wo= rk backwards through=0Athe PRF to figure out how many iterations this amoun= ts to. Making things even=0Aworse, the count is encoded in a weirdo fixed-= point format that can't be=0Apassed as an integer count parameter to anythi= ng because it's not, or=0Aalternatively that if passed as an integer has to= then be converted back into=0Aits oddball fixed-point format when written.= So:=0A=0A Replace the S2K 'count' value with a 32-bit integer specifying= the number of=0A PRF iterations to apply.=0A=0APeter.=0A From nobody Sat Jun 5 09:03:24 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02D63A274C for ; Sat, 5 Jun 2021 09:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 QBwyZa8N3tCg for ; Sat, 5 Jun 2021 09:03:18 -0700 (PDT) Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC213A274E for ; Sat, 5 Jun 2021 09:03:17 -0700 (PDT) Received: from [172.17.203.2] (port=56523 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lpYlX-0008Nu-0W; Sat, 05 Jun 2021 16:03:15 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1lpYlW-0006Uj-Uh; Sat, 05 Jun 2021 18:03:14 +0200 From: Florian Weimer To: Daniel Kahn Gillmor Cc: IETF OpenPGP WG References: <20210602230847.3593022-1-dkg@fifthhorseman.net> Date: Sat, 05 Jun 2021 18:03:14 +0200 In-Reply-To: <20210602230847.3593022-1-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 2 Jun 2021 19:08:47 -0400") Message-ID: <87eedg9u4d.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] WIP: bind wire format representations to specific pubkey algorithms X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2021 16:03:23 -0000 * Daniel Kahn Gillmor: > The OpenPGP standard is in a bit of a mess when it comes to wire > formats for public key algorithms. > > There are not infrequent reports of interoperability problems (most > recently https://dev.gnupg.org/T5464), and difficulties for > implementers in understanding what is expected. I think this issue also affects RSA data because the way OpenPGP specifies the operations, they are octet strings of a specific length, not integers, and may including leading zero bytes. From nobody Sat Jun 5 10:32:22 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4373A299F for ; Sat, 5 Jun 2021 10:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 4QxU_Gaq4fSy for ; Sat, 5 Jun 2021 10:32:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B403A299D for ; Sat, 5 Jun 2021 10:32:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3E6BE38AF2; Sat, 5 Jun 2021 13:32:47 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rja8Jt2o8kgv; Sat, 5 Jun 2021 13:32:46 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E4A8038AEE; Sat, 5 Jun 2021 13:32:45 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 747C11D3; Sat, 5 Jun 2021 13:32:12 -0400 (EDT) From: Michael Richardson To: Daniel Huigens , Daniel Kahn Gillmor , IETF OpenPGP WG In-Reply-To: References: <20210602230847.3593022-1-dkg@fifthhorseman.net> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] WIP: bind wire format representations to specific pubkey algorithms X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2021 17:32:21 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Daniel Huigens wrote: > Once we do specify a new public key algorithm (e.g. post-quantum), as > opposed to just a new curve (my expectation is that adding post-quant= um > algorithms will be the next "crypto refresh", and that we will never > need a new curve after Curve448), I fully agree that we definitely > shouldn't do this byte-string-in-MPI thing again. When we do so, we > could specify a new octet string type, or something else. But I'm not > sure that between Curve25519 and Curve448 is the correct place to "dr= aw > the line in the sand". I don't think that it's right to think of post-quantum as being a crypto-re= fresh. That is, replacement of one set of algorithms with another. Rather, I think it's better to try to think about this as being multiple algorithms present at the same time. having said that, we shouldn't allow better to get in the way of good enoug= h. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmC7tRwACgkQgItw+93Q 3WWjwAf/QyFKkWfW7Jjl8GLKVyn5U1O4RI10DGeletiLhoFu5wPbI7G3o+5HtTC6 YTlFRa6/aj2742Yy7aWiJCdF/D+zJ2Etl8YH50caN9NgRUaNwn0TdDD3pXioLLy4 WobbBbT3zObXn0KOwE5hQsJehJiDMzuSlG2jZ0c7D+bYplv7h5hC3sYOx9656UVS CHM6xmA/pKiWH/XvIUsNruY2tAQHuLuPthP6wgcyTc3hmo9CZP+LVVpRQAiPZa2F EQo/LcHGH7LU6wvRGbQdIZ3mZGesmaykWb/o5+V8CZ8XIHlFuSwbDB/AG47AUcNo UUvPa399l1DFf83zI8AbALGOfxWw2g== =++46 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jun 5 10:55:09 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5993A2A9B for ; Sat, 5 Jun 2021 10:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.305 X-Spam-Level: X-Spam-Status: No, score=-1.305 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=IHpZf8UY; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=mTrfjDwD 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 SF4UJL-CURkw for ; Sat, 5 Jun 2021 10:55:01 -0700 (PDT) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8968A3A2A97 for ; Sat, 5 Jun 2021 10:55:01 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1622915700; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=weaq5Ztiw7MU5M/UhDp9a25ryn269nwVS96C++3zQrQ=; b=IHpZf8UYQWu7TTps2eWaY21I+UEZtU606XGJ+I7TX9GoqWD5i1I4MmwQH/kS+wNN/2QnY y8anln/8DUU5F/GDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1622915700; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=weaq5Ztiw7MU5M/UhDp9a25ryn269nwVS96C++3zQrQ=; b=mTrfjDwD6r/gdnp3aI3aDWPzsDSPaVbGfQNkGf3VOzDGEM3kcW63/TF8tSUwziFLEWiN7 u1FuYCETq2wc5E9JXzyZS3HAGoqjjN+VPDOWEtblbp9BLxxQqkhffoob8ulDhB/CHgarrae yfeNse/3EtIa/zZEez2ZCOtjpN57GDSPl/3lBg8NiY6bxcSPqMM/k8WDaC5pVv2nglqeZDU GzoUKZ+UbKOhQXo2yO+pwOextd9K9oj5VFhZ7w6gKXsWqSbjCuuxk0FDtre7x5fzTpXXXM2 uRUtXM4ChKFqNMPEZ58GtVamvg32EjYN6eWivcxlvef67QSGKVNwqJL2j9Aw== Received: from fifthhorseman.net (ip68-0-212-178.ri.ri.cox.net [68.0.212.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 13259F9A5; Sat, 5 Jun 2021 13:54:59 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 7A43E206E3; Sat, 5 Jun 2021 13:30:27 -0400 (EDT) From: Daniel Kahn Gillmor To: Daniel Huigens Cc: IETF OpenPGP WG In-Reply-To: References: <20210602230847.3593022-1-dkg@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Sat, 05 Jun 2021 13:30:24 -0400 Message-ID: <874kecrzgv.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] WIP: bind wire format representations to specific pubkey algorithms X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2021 17:55:06 -0000 --=-=-= Content-Type: text/plain Hi Daniel-- thanks for your thinking and reading about this! On Fri 2021-06-04 19:27:16 +0000, Daniel Huigens wrote: > For what it's worth, I fully agree that the current situation with > Curve25519 is non-ideal and confusing, and that a simple byte string > would be better. However, we'll likely be stuck with it forever, and I'm > not sure if specifying a different wire format for Curve448 makes things > any simpler. I think this is a fair read -- whether i agree with it or not -- and i hope that we can have the discussion about what to do about curve448 *independently* from this proposed revision/clarification. I put my preference about curve448 in the commit message/comment section just to be transparent about my own thinking, but i don't think that the propopsal commits the WG to handling curve448 one way or the other. (there is a possible exception with the line the "This format is NOT RECOMMENDED for use when specifying future algorithms with OpenPGP, but it is necessary for handling pre-existing data." -- but if we parse that line as meaning "once the new RFC is out the door" it still gives us wiggle room to specify Curve448 in the way that Daniel is recommending here) So for this thread, i'd appreciate it if we can analyze the attempted clarifications offered -- i might have got them wrong, and i'd really appreciate more reviews to ensure that we've got them right. We can decide about curve448 later! Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYLu0swAKCRA+nXFzcd5W XO8FAP94hzAZZ5ymfYxaHaRsmcXMtSSACcUOtuhqYm2cX/1g3gEA9C0A28PDA8Nr 6u5lylI5HvXavBomQHTh+HgVoVytYgg= =r6Yv -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jun 5 10:55:13 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797C93A2A97 for ; Sat, 5 Jun 2021 10:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.305 X-Spam-Level: X-Spam-Status: No, score=-1.305 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=gq0GO0Qd; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=Q7kzas6D 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 vkgbImnGsOKF for ; Sat, 5 Jun 2021 10:55:01 -0700 (PDT) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F393A2A96 for ; Sat, 5 Jun 2021 10:55:01 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1622915700; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=TonyMQPcZSzEDwjAzAUkuexfueDjgNbxSdfKo0bhepM=; b=gq0GO0QdAwJ1D7+SYlry6DUhs5vlbGDRavAnmH+qkhQ/aDU1uYsCjq+ozJ1e4mDS3G/I7 zPTk4mecfzac0V9Bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1622915700; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=TonyMQPcZSzEDwjAzAUkuexfueDjgNbxSdfKo0bhepM=; b=Q7kzas6DBsP0fzhZ7RHt+yIaRgmBeW0AM/Mo6HXmHIOeAcwnnP8/bKB/skt5CpGIhVBFX 8QM5nLavb2x8uRiSfF5302TqjfXIg7etItxFCLNRXYhY4rlx8IUESYoBQNOgkptodJUZ+rN aYzBzDghxCOnW3jToJy6Cgbz6hFr3ysMZIS0qlQeHSzxD/sBQ/KEu1Fn16WbF2K2Detm7fy gHFng8DfYgieENBUcApiDu6QbPabS4xa5vy2fCpOKLwXi959TL8Q+M9KfsSjxolZ/Y5vhFa NafcGt5+saWZoz+dqn60R17Zq+nfWzC9uOMPpihcfs8IL6aDXah5Yy/5+RSQ== Received: from fifthhorseman.net (ip68-0-212-178.ri.ri.cox.net [68.0.212.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 2E320F9A8; Sat, 5 Jun 2021 13:54:59 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 95A4820824; Sat, 5 Jun 2021 13:31:58 -0400 (EDT) From: Daniel Kahn Gillmor To: Florian Weimer Cc: IETF OpenPGP WG In-Reply-To: <87eedg9u4d.fsf@mid.deneb.enyo.de> References: <20210602230847.3593022-1-dkg@fifthhorseman.net> <87eedg9u4d.fsf@mid.deneb.enyo.de> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Sat, 05 Jun 2021 13:31:56 -0400 Message-ID: <871r9grzeb.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] WIP: bind wire format representations to specific pubkey algorithms X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2021 17:55:07 -0000 --=-=-= Content-Type: text/plain Hi Florian-- On Sat 2021-06-05 18:03:14 +0200, Florian Weimer wrote: > * Daniel Kahn Gillmor: > >> The OpenPGP standard is in a bit of a mess when it comes to wire >> formats for public key algorithms. >> >> There are not infrequent reports of interoperability problems (most >> recently https://dev.gnupg.org/T5464), and difficulties for >> implementers in understanding what is expected. > > I think this issue also affects RSA data because the way OpenPGP > specifies the operations, they are octet strings of a specific length, > not integers, and may including leading zero bytes. This is an unsettling message, but I'm not sure I understand what you mean. Can you provide a specific example? Do you think the text of the draft needs to be updated to clarify RSA as well? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYLu1DgAKCRA+nXFzcd5W XGM5AP448tGDueUJuiH/qt8dkDTRI+NPp//ypnhRmkuJK+a5tgEAs28N9cKLkCE1 CYtDxStpS+vXrwHvGoQ6v1H9jhixngs= =hvuL -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jun 5 10:55:17 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373BE3A2A4D for ; Sat, 5 Jun 2021 10:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=ppKleZ7z; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=2CuKmLJI 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 Gx7yfcwtuQ4i for ; Sat, 5 Jun 2021 10:55:02 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A94973A2A98 for ; Sat, 5 Jun 2021 10:55:02 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1622915700; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=dDqeLSz3GssKhXD+bSc4Po5G+j/jayXALF81bf/Irrc=; b=ppKleZ7zcfqhAiBrCtP7X521V2BOnI7quVCXg6NcqSJQllUOORN605wQl/aKxgX3gId4x C8Dp9xVjWrpC/L/Cw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1622915700; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=dDqeLSz3GssKhXD+bSc4Po5G+j/jayXALF81bf/Irrc=; b=2CuKmLJIMaO7Jso4yztJF9S8CQPwDxAxuuDp3JQyCgTIl8p3PCy8tyfQZHtalQebKqKAl p5633VcZmXlw6rOvvjQ5JfRV1SNl3lR/eoatVtQCGcIi1W3wTCx/T2SYciNeeE1R8/wMvSd 5jHIc82A1W62iBtN+DR28LBAonnf4kuW2nsoP1uT+ubJvweRqPZXwuqTGZHzxqibKtrqRgL nX7qW4KK5438Qp4x8mMbMDdDrfedVxPAlnFBp2THPa/ZJrS80pLI+u2D6gU/ntL6iTVFkHy WY+uzY25/moUfBDwrX0hE6Bz1T/VTfbr7I2p8oNv4PlPVtr+OFtetckoRC4A== Received: from fifthhorseman.net (ip68-0-212-178.ri.ri.cox.net [68.0.212.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 194B6F9A6; Sat, 5 Jun 2021 13:54:59 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0505F20928; Sat, 5 Jun 2021 13:41:29 -0400 (EDT) From: Daniel Kahn Gillmor To: Michael Richardson , openpgp@ietf.org In-Reply-To: <376548.1622830236@dooku> References: <87lf7q6sh0.fsf@fifthhorseman.net> <376548.1622830236@dooku> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Sat, 05 Jun 2021 13:41:27 -0400 Message-ID: <87v96sqke0.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2021 17:55:07 -0000 --=-=-= Content-Type: text/plain On Fri 2021-06-04 14:10:36 -0400, Michael Richardson wrote: > > (2) appears to prepare for keys larger than 65536 octets. This looks > > like post-quantum planning to me, but we are not including any PQ > > schemes in the specification, and it's not clear that this change on > > its own would be sufficient to support such a new scheme (especially > > because there doesn't seem to be any CFRG consensus on what PQ scheme > > to endorse yet). > > Sure, but wouldn't it help a v5 implementation to more intelligently skip > such a thing? I don't know if we can support multiple signatures with > different algorithms. Would it? In what context? The change for (2) has to do with how to structure data fed into a hash algorithm for a certification ("key signature") but isn't anything on the wire. Honestly, i find (2) the least problematic of the changes listed -- it doesn't affect the wire format, and it's just a slight change to the hashing algorithm which already needs a special case for the bytes hashed (0x99 for v4 vs 0x9a for v5). If the WG decides that the change in (2) is worth keeping because it just might come in handy for some as-yet-unspecified scheme, that's a plausible argument to me, but i don't see how it helps anyone skip over anything. Can you explain more? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYLu3SQAKCRA+nXFzcd5W XERWAP9QGT0VPQVGdG/vpLFCxhnomW5v86ZceZGMKbBlK+xLqQD+INEiv884O8me dejMnq6lCCL5LJtiybzMNefoVQnMqgE= =d+8X -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jun 5 10:55:21 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022C73A2A4D for ; Sat, 5 Jun 2021 10:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=tozYrJTv; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=i8SWpZOY 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 4uSgdT2zhfks for ; Sat, 5 Jun 2021 10:55:03 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B94A3A2A99 for ; Sat, 5 Jun 2021 10:55:03 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1622915702; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=/4+RtLsO2vMDaJ/BWyhWwzONWmpLq154c66mX9DLmTg=; b=tozYrJTv/MmKUP1G8kRsXv2gDtyGLr82iktcYbrx1AcHBaTuZK9xopdXwc7HiIRvEdjeM m/5330XWsmxcSwmDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1622915702; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=/4+RtLsO2vMDaJ/BWyhWwzONWmpLq154c66mX9DLmTg=; b=i8SWpZOYuBmvY90sd7C2QmVO5hstUmsp+YRicQUT99bt82kBdAMuxoeo+pbekA+ge/vMR Tcb+MEUchyb3IAQD039bmn1gwascdsETpHAEv6p1cq0lXlldH496/kFx++gT4nL4b9rwf3M kZNAZxw85y/VcaY9ihexjUZskKzeurEoHmnfus8D4Z2Ga0ntwhVpv4CjPwXffYq7splY/O/ goU+BKCdzsuHkH9mbrWs7zr5FHD+0PecW178ZY9N/cFcsJ6mtKW0ezV1Zq0yJCbaHG4Yeub 4VtRSMfMYXXH0I/qpMTgNlAruJGI+QjbAEi65gMGnGHTN0oOfYVOIuNPXIqg== Received: from fifthhorseman.net (ip68-0-212-178.ri.ri.cox.net [68.0.212.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 6638DF9A7; Sat, 5 Jun 2021 13:55:00 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 189FD2087A; Sat, 5 Jun 2021 13:37:13 -0400 (EDT) From: Daniel Kahn Gillmor To: Peter Gutmann , "openpgp@ietf.org" In-Reply-To: References: <87lf7q6sh0.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Sat, 05 Jun 2021 13:37:10 -0400 Message-ID: <87y2boqkl5.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2021 17:55:08 -0000 --=-=-= Content-Type: text/plain On Sat 2021-06-05 12:22:38 +0000, Peter Gutmann wrote: > Daniel Kahn Gillmor writes: > >>Specific v5 changes > > Another thing I'd like to see changed in v5 is the incredibly annoying way > OpenPGP handles its PRF. For every PRF use on the planet except OpenPGP, you > specify the number of iterations of the PRF to be applied. For OpenPGP you > specify the number of bytes to output and then have to work backwards through > the PRF to figure out how many iterations this amounts to. Making things even > worse, the count is encoded in a weirdo fixed-point format that can't be > passed as an integer count parameter to anything because it's not, or > alternatively that if passed as an integer has to then be converted back into > its oddball fixed-point format when written. So: > > Replace the S2K 'count' value with a 32-bit integer specifying the number of > PRF iterations to apply. I don't think the S2K updates for v5 have made it into the crypto-refresh draft yet. So i appreciate this comment but i hope we can delay it until we address new forms of S2K (see e.g. commit 6337518cd35ee416129959982a10df85548b2117 in the step-by-step branch, which is not yet merged). --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYLu2SAAKCRA+nXFzcd5W XP9MAP41KBzn0AkEQGJAG5ltWz3jH5OnjgM67kVTFA2ev4vLeAEA0NQP+pPuiv4Z iPM1glBvPduW19lK/12/fvotEjZAyA4= =EAYt -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jun 5 11:04:15 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C54E3A2ADF for ; Sat, 5 Jun 2021 11:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=wicSmCSU; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=THADvA/c 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 aqks-RkR13hK for ; Sat, 5 Jun 2021 11:04:08 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA2093A2ADE for ; Sat, 5 Jun 2021 11:04:08 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1622915702; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=OA41EgKq50o4fxWJCzq2X0vhnZ2+tBe97fDpxwdWoQQ=; b=wicSmCSUGo5BrIspq8le3k95F+UWNV+5PBnH5pE5bcksHEjWdopimFCJo1S1y5Oejamd2 UTe0Wv/sdDslqfWDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1622915702; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=OA41EgKq50o4fxWJCzq2X0vhnZ2+tBe97fDpxwdWoQQ=; b=THADvA/cpOUtryanpj1QQhuX4Iwh+4nsQioFKSubz38/LwfcB4ulUvUy1xiTL14GMll4h l4I5/qsIdhkIDMvDc5AQvFggSVwIg9Av+jvWR5iq4Rp6UTH45yMGa/PQ8mB+urZPeAfILOk k2FuFwKksYeRkntjCNraZ/j7BN/zzxkyit0A4UGD+Y22PEVSvdOhqrNvRT5G3RuePhAdWmw ioCIa+dD33z4El1Bxfy0o3a+ftjmstGEx81duIXrTseI2c0cEzOPodTMrxtONmDgdx1bu1W Iub1b5aoZCA1neRzD/cPRG0qFTaW0f/gaXSqI61tHw60WDTP9JeAzxsLpAow== Received: from fifthhorseman.net (ip68-0-212-178.ri.ri.cox.net [68.0.212.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 6A49DF9A9; Sat, 5 Jun 2021 13:54:59 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id C606220B32; Sat, 5 Jun 2021 13:54:56 -0400 (EDT) From: Daniel Kahn Gillmor To: Peter Gutmann , Daniel Huigens Cc: "openpgp@ietf.org" In-Reply-To: References: <87lf7q6sh0.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Sat, 05 Jun 2021 13:54:54 -0400 Message-ID: <87sg1wqjrl.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2021 18:04:14 -0000 --=-=-= Content-Type: text/plain On Sat 2021-06-05 11:20:48 +0000, Peter Gutmann wrote: > The first thing to do when "fixing" SHA1 fingerprints, meaning breaking all > existing fingerprints on the planet, The draft as it stands doesn't "break all existing fingerprints on the planet" -- it just says "when you're making a new OpenPGP key, make it v5 and you and your peers won't have to think about SHA-1 any more when using this key". By using a v5 key an implementation would also be effectively signalling its compatibilty with any updated MTI choices (which we haven't gotten to yet, because we're still wallowing here). This is a change that, granted, should have been made a decade ago so that we could have some deployment by now. But better late than never. > is to define what properties they need to have. I can't think of > anything for which SHA-256 is OK but SHA-1 isn't, so before > arbitrarily throwing SHA-256 in there we'd need to define what's > needed for a fingerprint algorithm to see why -1 doesn't meet the > requirements, and whether -256 does. We've been over this ground before in the WG, and i don't think anyone who thinks about it deeply will disagree with you re: collision resistance. Nonetheless, fingerprints show up in many places, and many implementations use them as unique identifiers, and can display weird/broken behavior when encountering collisions, even if they're sourced from the same (potentially malicious) actor. Do we want to encourage that kind of booby trap? Furthermore, having to constantly defend the use of SHA-1 when it is known to be deprecated *in other contexts* is a tiresome exercise, and i think it'd be great if the OpenPGP community could move past it. We settled in the past iteration of this WG on SHA-256 as a non-controverisal replacement, which is why it was re-merged into the crypto-refresh draft. If folks really want to re-litigate it, i suppose that's possible, but i think we have bigger fish to fry (can we get to those MTI changes, for example?) and I hope folks will think clearly about whether such a detour is worthwhile. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYLu6cAAKCRA+nXFzcd5W XLWsAQC4mmbyK+VzhI21YyP1Bby7koFC0AUzO/axeJEIDc1ryAD/ad2KPzCbTHJf i8t1Ud6jecYh+S6SAOkuvrUyDaUkvAk= =V09+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jun 5 11:16:24 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454A53A2B39 for ; Sat, 5 Jun 2021 11:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 a_Pb6WpW2azE for ; Sat, 5 Jun 2021 11:16:17 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 610033A2B34 for ; Sat, 5 Jun 2021 11:16:17 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Fy79p3q0pzFHR for ; Sat, 5 Jun 2021 20:16:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1622916974; bh=uDlSkP7XCnZO1v1aq4U9SwywND+vxr5sy/+jKwEa/ug=; h=Date:From:To:Subject:In-Reply-To:References; b=Oumo13AuOUQIaCqoGv/UHrBr0GKCeAngPi29RdDNoQAe5nEcRcMNrgJRE6TeDNbr8 c8VPF5m/DiPWW1zinzzl432BjO2lqe7DZDd1TuLWzNCYfcXyZKt6MWSxsOH03i0+PJ BdC/SI99g9SEaX8N5jMtOb7456x5W/HKenP2vOnM= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id oDBvI-e8yVLh for ; Sat, 5 Jun 2021 20:16:13 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Sat, 5 Jun 2021 20:16:13 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 04D507D716; Sat, 5 Jun 2021 14:16:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 005447D715 for ; Sat, 5 Jun 2021 14:16:11 -0400 (EDT) Date: Sat, 5 Jun 2021 14:16:11 -0400 (EDT) From: Paul Wouters To: openpgp@ietf.org In-Reply-To: <87sg1wqjrl.fsf@fifthhorseman.net> Message-ID: <3c983dd-996d-98b-3593-abd046472cd3@nohats.ca> References: <87lf7q6sh0.fsf@fifthhorseman.net> <87sg1wqjrl.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2021 18:16:22 -0000 On Sat, 5 Jun 2021, Daniel Kahn Gillmor wrote: > Furthermore, having to constantly > defend the use of SHA-1 when it is known to be deprecated *in other > contexts* is a tiresome exercise, and i think it'd be great if the > OpenPGP community could move past it. This is the main argument for me. Crypto libraries are trying to phase out and disable SHA-1. Some crypto libraries have API's that allow the caller to say "yes I know, you can trust my use of it" but not all libraries have that. So it is useful to just move from SHA-1 to SHA2 for this reason alone. Paul From nobody Sat Jun 5 11:23:42 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000823A2B73 for ; Sat, 5 Jun 2021 11:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 1uLXhgE_X015 for ; Sat, 5 Jun 2021 11:23:36 -0700 (PDT) Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440353A2B70 for ; Sat, 5 Jun 2021 11:23:36 -0700 (PDT) Received: from [172.17.203.2] (port=43495 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lpaxI-00023y-BH; Sat, 05 Jun 2021 18:23:32 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1lpaxA-0008A9-S5; Sat, 05 Jun 2021 20:23:24 +0200 From: Florian Weimer To: Daniel Kahn Gillmor Cc: IETF OpenPGP WG References: <20210602230847.3593022-1-dkg@fifthhorseman.net> <87eedg9u4d.fsf@mid.deneb.enyo.de> <871r9grzeb.fsf@fifthhorseman.net> Date: Sat, 05 Jun 2021 20:23:24 +0200 In-Reply-To: <871r9grzeb.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sat, 05 Jun 2021 13:31:56 -0400") Message-ID: <871r9g9nmr.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] WIP: bind wire format representations to specific pubkey algorithms X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2021 18:23:41 -0000 * Daniel Kahn Gillmor: > Hi Florian-- > > On Sat 2021-06-05 18:03:14 +0200, Florian Weimer wrote: >> * Daniel Kahn Gillmor: >> >>> The OpenPGP standard is in a bit of a mess when it comes to wire >>> formats for public key algorithms. >>> >>> There are not infrequent reports of interoperability problems (most >>> recently https://dev.gnupg.org/T5464), and difficulties for >>> implementers in understanding what is expected. >> >> I think this issue also affects RSA data because the way OpenPGP >> specifies the operations, they are octet strings of a specific length, >> not integers, and may including leading zero bytes. > > This is an unsettling message, but I'm not sure I understand what you > mean. Can you provide a specific example? RFC 3447 section 8.2.2 says this about signature verification: | 1. Length checking: If the length of the signature S is not k octets, | output "invalid signature" and stop. Due to the way MPI encoding and decoding does no round-trip leading zeros, some valid OpenPGP signatures (about one in every 256) cannot be validated by PKCS#1 implementations that perform this length check. I guess every implementor who tries to layer OpenPGP on top of an existing PKCS#1 implementation will eventually learn about this, but I suspect I'm not the only one who was surprised by this. From nobody Sat Jun 5 13:29:15 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C96E3A2F0E for ; Sat, 5 Jun 2021 13:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 T4RNE5LL8osU for ; Sat, 5 Jun 2021 13:29:09 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302E63A2F0D for ; Sat, 5 Jun 2021 13:29:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 77C5138AE4; Sat, 5 Jun 2021 16:29:41 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bnvtCnkhjckK; Sat, 5 Jun 2021 16:29:41 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 00B4038AE3; Sat, 5 Jun 2021 16:29:41 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1551967E; Sat, 5 Jun 2021 16:29:07 -0400 (EDT) From: Michael Richardson To: Daniel Kahn Gillmor , openpgp@ietf.org In-Reply-To: <87v96sqke0.fsf@fifthhorseman.net> References: <87lf7q6sh0.fsf@fifthhorseman.net> <376548.1622830236@dooku> <87v96sqke0.fsf@fifthhorseman.net> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2021 20:29:14 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Daniel Kahn Gillmor wrote: > On Fri 2021-06-04 14:10:36 -0400, Michael Richardson wrote: >> > (2) appears to prepare for keys larger than 65536 octets. This lo= oks >> > like post-quantum planning to me, but we are not including any PQ >> > schemes in the specification, and it's not clear that this change = on >> > its own would be sufficient to support such a new scheme (especial= ly >> > because there doesn't seem to be any CFRG consensus on what PQ sch= eme >> > to endorse yet). >> >> Sure, but wouldn't it help a v5 implementation to more intelligently= skip >> such a thing? I don't know if we can support multiple signatures wi= th >> different algorithms. > Would it? In what context? The change for (2) has to do with how to > structure data fed into a hash algorithm for a certification ("key > signature") but isn't anything on the wire. Assume in the future that we have keys larger than 64K octets. We are doing that, not because there has been a quantum event, but because we are prepar= ing for it. We may still not even be sure which PQ scheme is the right one. (There are multiple keys present, and possibly multiple signatures over both end-user-data, and over keys) A v5-capable tool, which does not speak these new formats can still process the packets. It could also verify that these large keys are signed by our legacy algorithms. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmC73pIACgkQgItw+93Q 3WVcJQf/evEJ3BFFKc8YDsY2+6E6n6+j2Nf/dE3RaYHkw4WhsUX50WzwJI5J1KGn mf0Z3+qi8NjxB7cXjhIkWuieY4o6X15FpCyKGfCcMGMHANDCA+m+c5WgGevgw1ch 7zd4DR3yj045eBcGfL82jvw7U1Pto0FdKzaJ6d4rXmeJeaFnJ7S/zqBjxfRMZPs4 IOMzw9OXnf0BUvNfOBmZD/08FXZaFMA0AijIwid7UVWtzxWQkGteBGHZsc9mJh3j x37yZZyomHMPpy7tV/YJzEUUGXtdogHRZcNXc5oZ5RaQxVugnJoQ1i9OIuC3S5Tm XJ0qtyU9BMbu1OJXdPdQF5m8Q7ChJw== =CYPq -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 6 00:54:02 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3DE3A0E19 for ; Sun, 6 Jun 2021 00:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_BAD_THREAD_QP_64=0.998, SPF_HELO_NONE=0.001, SPF_NONE=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 s5PmK8BSIya4 for ; Sun, 6 Jun 2021 00:53:56 -0700 (PDT) Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [180.189.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4AE3A0E1B for ; Sun, 6 Jun 2021 00:53:55 -0700 (PDT) Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2237.outbound.protection.outlook.com [104.47.71.237]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-85-vC1kLAkUMsmnSOhJfVgnew-1; Sun, 06 Jun 2021 17:53:45 +1000 X-MC-Unique: vC1kLAkUMsmnSOhJfVgnew-1 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com (2603:10c6:10:10b::10) by SYBPR01MB6319.ausprd01.prod.outlook.com (2603:10c6:10:107::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.22; Sun, 6 Jun 2021 07:53:41 +0000 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::9965:92dd:f5b:87a7]) by SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::9965:92dd:f5b:87a7%6]) with mapi id 15.20.4195.029; Sun, 6 Jun 2021 07:53:40 +0000 From: Peter Gutmann To: Daniel Kahn Gillmor , Daniel Huigens CC: "openpgp@ietf.org" Thread-Topic: [openpgp] v5 in the crypto-refresh draft Thread-Index: AQHXWqjxZgm3Nb8iZ0mMkTayPQSTdA== Date: Sun, 6 Jun 2021 07:53:39 +0000 Message-ID: Accept-Language: en-NZ, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [14.1.76.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6c4d52f4-32f3-4612-ccab-08d928c03323 x-ms-traffictypediagnostic: SYBPR01MB6319: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: +wV5+yZVCmdRJGI2pintGSLRfVhnE9wXQq8U/iT3plTTnEonmnww4hSkkAjap5REXwI8Cgzrv/FyxYkU3faw9TlKDM9l4nPDwi2boGjm/mlAoA7RchfMOl05qwPo7mLd33Fxyh2RClDjvr9QpIbwXa1Un3CkmEp7cE02NKOY0cyrC5LCLXR0ZbRJR4x/GvslHCKNEErqKRsBQuR9BUXTheUT2/TYU2249x3kazjgVHAXyQ5PnJjp3BvJ2ekVHgBUEdisGd9asQIxSzTi4etYkCxfxA8UG/WVp2D3lwtJh6ylObiOQ1AlhGd0hOzUqLIfiNzXpkB/3JOYyZ0ON9xR/1fPOPexJaOLrQRS7oWx49s5Euv0tJauGdHezez77dEDILgsbD9dLpoM83RCfDn5pcn8X2lVsevQAXLgARAn04oUnELksr0SoVUkrzdQabWgM0YmRfbdf+KkLyvgPX/Q0ciIyGU7Hy9ZbOpnmSsav5aK6w/rm+i/JkHEhWQHLYLP5Qq4Ny7dj+3S8Kz+9JpuNYuxNbXs3PNsHqZPd4Z45ajOu2rfuqNF/jy98qzHZ30lxkCooMU937mWS52wbu3qFk1TgkbSReLxiMsOf7Bt4LE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6251.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(136003)(346002)(396003)(376002)(8936002)(8676002)(316002)(786003)(4744005)(186003)(26005)(110136005)(4326008)(122000001)(33656002)(52536014)(6506007)(66946007)(86362001)(66476007)(66556008)(64756008)(66446008)(7696005)(76116006)(2906002)(71200400001)(5660300002)(38100700002)(478600001)(55016002)(9686003); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?uAFRH06tpH7ylpIKWUT43QwLLpg15x59rEBKaHEIQ+p0IfLV/ARDnAw1/g?= =?iso-8859-1?Q?dzXiDYzqdVOmz8joQj44C6eoVSEwFkVA1J7Qz2yWj0n854aajgsRagtznE?= =?iso-8859-1?Q?OznCnOWVwZ+Yl0SeZ0ZD3pLi3pCGQjDRc08BC+xwAbrw12DB6LKqNMOYGj?= =?iso-8859-1?Q?zUKeiJUtdm+5gFa7mD03uD7vPGPKGlFBL7/CV9lRSTRZVLJVR9A9TP+OaX?= =?iso-8859-1?Q?JcbfaQUfWHvHihCiwZXM4Lr6Q20xw0aw9L46eaoo5Q6NKnPQfMVJeGgMwe?= =?iso-8859-1?Q?+of0Zvz0nQniw4NbsxQcpmqtYCCY/6EBCvXQgQG0FJ8TkFTq8GdObmoVGD?= =?iso-8859-1?Q?LzmSFro28PccqDNMoBgao4+jIXBkA7dx4jUR/Xo5tWZ7G5detYjy+nyQvi?= =?iso-8859-1?Q?Ff87q/152lPnW3ysqAXq+ryJ1SLnIB8mG09DZP1vtuB8XBdroU9mo5AvYI?= =?iso-8859-1?Q?b1nJ8XYlJjSIZGT01cHjYSjBVQ9pp+RC+pz3D5UtacshrraEt2aWRi3J5M?= =?iso-8859-1?Q?v0QXALrd2Pufi7gtyiq9lYCJVNd4RYn63luprhhMienLTO8D4t7uFjMBFW?= =?iso-8859-1?Q?w32sVY75wsFDckY6ABlFvcxFj6YpkicT6ZGBzELuwn/Hbe1joJl71tNOxg?= =?iso-8859-1?Q?a5VyHhg6C6+QWS3KDoG4+ewob04nOQgSDq+HOEOp7e29rfIIJyvrbBJhp2?= =?iso-8859-1?Q?NRwYAlzdOgRDzIDKwENMBZ+rcK9A1WYS/ty6G9OEQ/h6kC9xkiIHpbisEL?= =?iso-8859-1?Q?Y+Rb9WHecsrv4VrpbkHiO4Qgnh+s3lVY+yVsVBcssxz8AO8p7nM7X1jiBC?= =?iso-8859-1?Q?89lkoaZvksZzQoO7NAsDq9LkLruCYCvNYC0UZioFuUBfj2QUb2EM+fRlPL?= =?iso-8859-1?Q?5CA2Cozh7ntpPYPkkvSUUQkF7YpotIRRbXTzuGjijblsc27gOfdnjEnJpx?= =?iso-8859-1?Q?cuZqEg8QyemSctJ3udyRmtRiSFzMppgLnWtn+LBYPm3IyIPAK3FLhsHwAw?= =?iso-8859-1?Q?yOnUhY5xmeakR2Imr1nubygfQdUpSxqRjeDbP+GhlI6CynH4tqUyi/viv0?= =?iso-8859-1?Q?rpiHYXyvZ51E4Pp0jJ0Ti2LBiEba5CiL3CL8IMuBod5ri/7rxMRLpi/xQU?= =?iso-8859-1?Q?rXt24mZEYygZRT9Pq5KHu3wWWMJ+Q3ehoq4aCPpDiqSuTpAX5GBVE+Bznj?= =?iso-8859-1?Q?Rt2Yne2V8UDDTPqBpuuxGd9xof8TIBvX6XZxW484U1LvCBFZzOqmAnUNQm?= =?iso-8859-1?Q?X2Bb8pl5bldyvlIV0UiT17y9pFNl8/57aZi1+JFlDWi5TJj6N5cdYuXzVR?= =?iso-8859-1?Q?QtPkNrK9BvSEF0s0wPePKeTLCKM/m0FuPJfL2JWgvIDIj0c=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6251.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6c4d52f4-32f3-4612-ccab-08d928c03323 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2021 07:53:39.6346 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: baKqTxW3FRtKmL83F+9TFC5W4eWkhLQl28mWcWgPgKfoL1x9qdKIkhV3jrNIUXUMSHc7FlwB6rQXk7R1v5VThiQpPtWGXm97tpb0AmVBZp4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYBPR01MB6319 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cs.auckland.ac.nz Content-Language: en-NZ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2021 07:54:01 -0000 Daniel Kahn Gillmor writes:=0A=0A>If folks really want to re-litigate it,= =20=0A=0AOh, I don't want to re-do the whole debate but was more thinking t= hat the=0Adraft should provide a rationale for why -1 was dropped in favour= of -256,=0Aboth to explain to implementers and users who aren't on the mai= ling list what=0Aproperties are and aren't required for fingerprints, and t= o provide guidance=0Ain the future when it's decided to move off -256 to so= mething else.=0A=0APeter. From nobody Sun Jun 6 08:12:37 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4BA3A1E40 for ; Sun, 6 Jun 2021 08:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=zZsmX+aJ; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=4eljZ4dC 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 FUrgFIFZj0sZ for ; Sun, 6 Jun 2021 08:12:30 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC923A1E3D for ; Sun, 6 Jun 2021 08:12:30 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1622992347; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=CVbZ3P3p2b6+YLZbQqlnrAcrtBqf56SXH6X3vTA25To=; b=zZsmX+aJfuLZXdFqX3yt9BCMx3yXa33D+K8pEcUIaLdnH/+ywGwy5QBO46WULZbJgDb/s Dm5WwxjKPwlWr50Cg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1622992347; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=CVbZ3P3p2b6+YLZbQqlnrAcrtBqf56SXH6X3vTA25To=; b=4eljZ4dC46/fKT4L6vj7tEJ8dSkYUoUvLNYv4F1EdRyXyrgcomfBGYEmh5e+Z3Rr6ujC8 zUHzVy2HmqlaubZJEgpdS0tWbVRpuKjycz3UkeoTd1aV1J4E5aPKeh8v1tLK1Fg4Q3121F+ wRQe8n/H8Nm8KjoLo35QXguLSg6Ya9DfN9oKwHJRs13G3tbtujXDZuIfYdQkDi7ExrA1LFS RuHC0eAgKBHScBL00bEuHgCtUuI3auva91epyQ3tTr1C0wnmBGuzwpdMfobJsvCq3b5JLFF SjvCR0TasC1vqRFDxxyGCRwcPCXGiGVvAtQ54owBb7Z0InuLtyO7YWvMjI1Q== Received: from fifthhorseman.net (ip68-0-212-178.ri.ri.cox.net [68.0.212.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 9B6CAF9A5; Sun, 6 Jun 2021 11:12:27 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 274CA204D8; Sun, 6 Jun 2021 11:01:09 -0400 (EDT) From: Daniel Kahn Gillmor To: Michael Richardson , openpgp@ietf.org In-Reply-To: <14974.1622924947@localhost> References: <87lf7q6sh0.fsf@fifthhorseman.net> <376548.1622830236@dooku> <87v96sqke0.fsf@fifthhorseman.net> <14974.1622924947@localhost> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Sun, 06 Jun 2021 11:01:08 -0400 Message-ID: <87mts3qbpn.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2021 15:12:36 -0000 --=-=-= Content-Type: text/plain On Sat 2021-06-05 16:29:07 -0400, Michael Richardson wrote: > Assume in the future that we have keys larger than 64K octets. We are doing > that, not because there has been a quantum event, but because we are preparing for it. > We may still not even be sure which PQ scheme is the right one. I think these are the right assumptions. > (There are multiple keys present, and possibly multiple signatures over both > end-user-data, and over keys) Each "key signature" (certification) is its own OpenPGP packet, right? and the context we're talking about here is a hash context that is used to calculate a key signature. While there is some zoomed-out view that might well have multiple signatures, and there might be other data signatures that happen over collections of information that do include keys, those contexts aren't relevant for this specific calculation. If the concern is how to "skip over" an artifact from an algorithm that you don't understand, i don't think this increased size field is relevant, because any implementation can just "skip over" the signature by skipping to the end of the signature packet (whose length is already known; this field doesn't appear on the wire), or not calculating the digest itself at all. > A v5-capable tool, which does not speak these new formats can still process > the packets. It could also verify that these large keys are signed by our > legacy algorithms. yes, i agree with this, though it is not "skipping over" -- it's "preparing for certifications of larger keys". We still don't know whether this is *sufficient* for dealing with whatever eventual PQ algorithm arises, but i agree with you that it seems to be *necessary* to handle them. It might be worth including change (2) as a precautionary gamble, since it doesn't appear to have any downside other than a slightly tweaked codepath during certification creation and verification. What do other folks in the WG think? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYLzjNAAKCRA+nXFzcd5W XNjeAP4l83Dh5hTX8m6IWTWU/IjyKzDgFxgMK/+NbUCu+xNrSAD/Y7Pif+oaBL6k SihQCJcH672BMaHSvMPlK2DimRe2agg= =F+bs -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 6 08:12:42 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77DF3A1E40 for ; Sun, 6 Jun 2021 08:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=8rcps7UR; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=vx4wZf0/ 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 CPNxl4CFYguw for ; Sun, 6 Jun 2021 08:12:30 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639583A1E3E for ; Sun, 6 Jun 2021 08:12:30 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1622992348; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=hPw1yuuJkeXjxl8S7Fm8WMXTj0eDymie3euGbseUqB8=; b=8rcps7URJYvhTo8TvMOobzD3oCpiaioHh5vq9mzexYdsHY07aJNxBtvUpCFB3Jn02DT5J Ur3DXtxzwFyY45QAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1622992348; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=hPw1yuuJkeXjxl8S7Fm8WMXTj0eDymie3euGbseUqB8=; b=vx4wZf0/a+bf/mqptkb084ezhEXbVa+TaEGOvv17NzdwVzfdRbMu6M3wdLEthh35/HDE/ rPWNw8GmcijCdYeT3gpltj5AITZeb0CPmQTajxHb8KKZ8z3pJXrzsbOtJFJMaCvj87qMqui iRs0x4zdHgo8+sTIQ0A91A7tgbZO3TnOlo/S1x5ut5ReC+7i97l3dp2WQO0F4Wp4RwJ7h2J oMnf/2Ss+mJIz0ETvk49urgieQORIpjzJb0dZBkn9Ng1kWOu83vXgu8I3vtxcuUQm8/51Um 3PXCBIIYvH/GyKDW0v2q0U4YgCg9hsgZjtABflxFRwIUqh3uklZr6QioDhHA== Received: from fifthhorseman.net (ip68-0-212-178.ri.ri.cox.net [68.0.212.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id F008AF9A7; Sun, 6 Jun 2021 11:12:27 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 8559620759; Sun, 6 Jun 2021 11:12:08 -0400 (EDT) From: Daniel Kahn Gillmor To: Florian Weimer Cc: IETF OpenPGP WG In-Reply-To: <871r9g9nmr.fsf@mid.deneb.enyo.de> References: <20210602230847.3593022-1-dkg@fifthhorseman.net> <87eedg9u4d.fsf@mid.deneb.enyo.de> <871r9grzeb.fsf@fifthhorseman.net> <871r9g9nmr.fsf@mid.deneb.enyo.de> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Sun, 06 Jun 2021 11:12:07 -0400 Message-ID: <87k0n7qb7c.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] WIP: bind wire format representations to specific pubkey algorithms X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2021 15:12:37 -0000 --=-=-= Content-Type: text/plain On Sat 2021-06-05 20:23:24 +0200, Florian Weimer wrote: > I guess every implementor who tries to layer OpenPGP on top of an > existing PKCS#1 implementation will eventually learn about this, but I > suspect I'm not the only one who was surprised by this. Good call, Florian. Can you propose language that would clarify this in the current draft as implementation guidance? seems like we might want guidance for both signature generation and verification. I've opened a request for a new test in the OpenPGP interoperability test suite to see whether any of the tested implementations can handle this: https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/-/issues/54 --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYLzlyAAKCRA+nXFzcd5W XDWkAQCo0xNKrtJHfFf6FdpWz0/3G1Pyl0agU/Af2aGTMWxtlAD+IF6aW60uOCAI dfmySfJjfqzkwLW/t5TJVBbvItqJoQ4= =LaQL -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 6 08:30:48 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5083A1EC1 for ; Sun, 6 Jun 2021 08:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 6RPo0cYt18eq for ; Sun, 6 Jun 2021 08:30:41 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44C8A3A1EBC for ; Sun, 6 Jun 2021 08:30:41 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4FygSF3RzDzFHk; Sun, 6 Jun 2021 17:30:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1622993437; bh=hXMKakM6VbTRYIDA1WpEG6ogXd4KtM1HHCMVxouaAJ8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=qT2X1MNqCB/UE4L5DXVSgCb4huAPSh8OQ1ct1y614YRrOCprSvjUtR+fQqU/ceujR uperboEYucr07b8rezrnTa5SJIk8j2V1ctsZhHsgsL5eC+Y6jwfIuGwuRy84oVua6a 8Fl5wX5LZYH6XlMWAOgLdwVSxp13kJ8mbl2gEftw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id FyzuyWzUxJEF; Sun, 6 Jun 2021 17:30:36 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 6 Jun 2021 17:30:36 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 49FAC7E041; Sun, 6 Jun 2021 11:30:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 48BC37E040; Sun, 6 Jun 2021 11:30:35 -0400 (EDT) Date: Sun, 6 Jun 2021 11:30:35 -0400 (EDT) From: Paul Wouters To: Peter Gutmann cc: "openpgp@ietf.org" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2021 15:30:46 -0000 On Sun, 6 Jun 2021, Peter Gutmann wrote: >> If folks really want to re-litigate it, > > Oh, I don't want to re-do the whole debate but was more thinking that the > draft should provide a rationale for why -1 was dropped in favour of -256, > both to explain to implementers and users who aren't on the mailing list what > properties are and aren't required for fingerprints, and to provide guidance > in the future when it's decided to move off -256 to something else. We are happy to accept such proposed text, please send it to the list :) Paul From nobody Mon Jun 7 03:14:02 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466383A0D27 for ; Mon, 7 Jun 2021 03:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YK6wUFSqx2r2 for ; Mon, 7 Jun 2021 03:13:56 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBA63A0D20 for ; Mon, 7 Jun 2021 03:13:55 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id bn21so21438401ljb.1 for ; Mon, 07 Jun 2021 03:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:references:from:subject:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=T1QErvhhmFMyo2ryqqk6xvw71icH+mUCUwlKiVerGs4=; b=U30UN2Op7Qi7QJUDaNEHEFwYzVgLf6tbxwHFraMcfJy71vlKWJPHLNYncNkdTglH5j S2/m79Mtxp4/+8aHVzFzZJdZjX6NqNBSZOuzAFfOriETdIViCs+sYddqfLjeiOdI48q8 iZz+cGw5zuq4il0U2EtbEA17TKqHQ3K50iIsgyV6Y2EkvpJgWltEtmvv6DmOybOT1D3m d6ZE9lmOnJe9gZb77RargGfM4yX9x5eLP4gYBv+Mot0iHLAIA1iIAhdtnneM7KCwTIAG NsgIgdg+zMkhOIBOgwLGfUpiy8Z6bbMTuuc0iMr2OkKOgVTx3zVxV4KbTqz/EXu1ZreJ Andg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=T1QErvhhmFMyo2ryqqk6xvw71icH+mUCUwlKiVerGs4=; b=Af96tQ7nMutLUBE3Y1gEyj5N0Zxhb0rHb/uNL+4ew1FbXAEg2bDWCq8rToocqthwxx JRfBfrZqOxgM+464JrarFOascPolh8nRzsUU5USrdGCIheXhYwEJXOYZzeUHfDOCXwSK Qg4BCjGy/07EuAyML41vnVQnOkyLFKjvuB9LSwx75SXW7E92IIIhatmELKLnZ+9dOMBj ZvSGvosEVEuBEYd5UlaQN7sdF7p30U7HmS3njYB3TStb9eeyp3C0T8KPhXhjVmDoFJAA tzRHzOT1B1rdCKrvNvMlDXItCUKJiBgKQTettT58+A1CuwdS7MOWfpNEqssw+vpqIbaH 5IjA== X-Gm-Message-State: AOAM530QeBHiDZ15VsDKifyTXV9OwUmAONwmLrh3w9GTsxy3ecoUYm5M YJ9SvgzXYVV1aWmKLUCWZIt5ZOB+w1DomQ== X-Google-Smtp-Source: ABdhPJx8HQ+YM3sU0ix97EJ+Ts1CLKsELHyhcyLpVGe1XiCi+QhZlJQ/qrUiv98TtwhMUigqJ7fzZA== X-Received: by 2002:a2e:870d:: with SMTP id m13mr14590061lji.250.1623060831769; Mon, 07 Jun 2021 03:13:51 -0700 (PDT) Received: from Inf-Mb2020.local ([46.229.60.172]) by smtp.gmail.com with ESMTPSA id w15sm681844lfq.94.2021.06.07.03.13.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Jun 2021 03:13:51 -0700 (PDT) To: openpgp@ietf.org References: <87lf7q6sh0.fsf@fifthhorseman.net> From: Nickolay Olshevsky Message-ID: <2e2495e8-6f4c-f842-3886-61cd696a6483@gmail.com> Date: Mon, 7 Jun 2021 13:13:50 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <87lf7q6sh0.fsf@fifthhorseman.net> Content-Type: multipart/alternative; boundary="------------9246AB38880EF3EA0321DA93" Content-Language: en-GB Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 10:14:00 -0000 This is a multi-part message in MIME format. --------------9246AB38880EF3EA0321DA93 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, It's slightly out of the original questions, but still related to the v5 = keys/sigs. Basically, given that year 2038 will come in 17 years, and previous RFC=20 4880 is already 14 years old without any replacement (yet), why v5 keys=20 and signatures still have 32-bit creation time? Or did I miss some discussion regarding this? On 04.06.2021 09:42, Daniel Kahn Gillmor wrote: > I've been reviewing the changes in draft-ietf-openpgp-crypto-refresh-03= =2E > I have concerns about most of the "v5" features currently incorporated.= > > ... > > Regards, > > --dkg > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp --=20 Best regards, Nickolay Olshevsky o.nickolay@gmail.com --------------9246AB38880EF3EA0321DA93 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

It's slightly out of the original questions, but still related to the v5 keys/sigs.

Basically, given that year 2038 will come in 17 years, and previous RFC 4880 is already 14 years old without any replacement (yet), why v5 keys and signatures still have 32-bit creation time?

Or did I miss some discussion regarding this?


On 04.06.2021 09:42, Daniel Kahn Gillmor wrote:
I've been reviewing the changes in draft-ietf-openpgp-crypto-refresh-03.
I have concerns about most of the "v5" features currently incorporated.

...

Regards,

        --dkg


_______________________________________________
openpgp mailing list
openpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

-- 
  Best regards,
  Nickolay Olshevsky
  o.nickolay@gmail.com
--------------9246AB38880EF3EA0321DA93-- From nobody Mon Jun 7 03:22:34 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1986B3A0D92 for ; Mon, 7 Jun 2021 03:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 DdfXsA8RbZ97 for ; Mon, 7 Jun 2021 03:22:28 -0700 (PDT) Received: from osse.kmail.bg (mx.kmail.bg [37.157.165.4]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C4523A0D93 for ; Mon, 7 Jun 2021 03:22:27 -0700 (PDT) Received: from straylight.m.ringlet.net (unknown [93.152.132.21]) by osse.kmail.bg (Postfix) with ESMTPSA id 0F6E1103 for ; Mon, 7 Jun 2021 13:22:25 +0300 (EEST) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 6200e2 by straylight.m.ringlet.net (DragonFly Mail Agent v0.13); Mon, 07 Jun 2021 13:22:24 +0300 Date: Mon, 7 Jun 2021 13:22:24 +0300 From: Peter Pentchev To: openpgp@ietf.org Message-ID: References: <87lf7q6sh0.fsf@fifthhorseman.net> <2e2495e8-6f4c-f842-3886-61cd696a6483@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/HMZzMPu6lbSf3ev" Content-Disposition: inline In-Reply-To: <2e2495e8-6f4c-f842-3886-61cd696a6483@gmail.com> Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 10:22:33 -0000 --/HMZzMPu6lbSf3ev Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 07, 2021 at 01:13:50PM +0300, Nickolay Olshevsky wrote: > On 04.06.2021 09:42, Daniel Kahn Gillmor wrote: > > I've been reviewing the changes in draft-ietf-openpgp-crypto-refresh-03. > > I have concerns about most of the "v5" features currently incorporated. > >=20 > > ... >=20 > Hi, >=20 > It's slightly out of the original questions, but still related to the v5 > keys/sigs. >=20 > Basically, given that year 2038 will come in 17 years, and previous RFC 4= 880 > is already 14 years old without any replacement (yet), why v5 keys and > signatures still have 32-bit creation time? >=20 > Or did I miss some discussion regarding this? Obviously not speaking for any of the people who actually work on this, but you need to keep in mind that the time field is defined as an *unsigned* 32-bit number, so we'll have another 68 years after the year 2038 to take care of that. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@debian.org pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --/HMZzMPu6lbSf3ev Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAmC981wACgkQZR7vsCUn 3xOtfhAAzhpTraiBVZ7JbbVrkZnh4tGvA7GxaPKM391xxLTSV6gy0Bx0bW3cHl58 APLDVcG4RsEYUvIgABQbow94nDQDJzgdhqGW2rQ1pbFC0krPLriQYD+VesQvJlvS zwK8D9svs8KIGLXc418Lug2KyqxJcJVhMocCL1D/ODR/tpfZP5T3xtQ8KErmZbxB PCdPfNHXjVj5CYJElcDtJg51FIFmIUoS2N6aCc/15jxkW+TSk874R29EuhBXoSPW Qrnyybb1cyzZckkpAm+m+N0Y9ucE4Gb7AaE8vRT9Dn2QMJRTNM3GTD3mWEtnuVPv 6xXxgbWE8od1tcsDOsLKGQAU04pv1pI1QV8mf1OofJwygev8D+pdtQmJyp/du+l/ knj81L+k/uJOr/kWy+3f7r3IiCq5nu1Eqlg6k0zITzUAB+xNzrjcr+fO4Kd/Pdwf ZsGUmhMi+FPrW3sGHFp0nLj8EViozyPg3ziXhTyBga3aCs52pphfETirs3dRBARl 6rotFNy+zkIY1UI6oXBVCOFON+UIj3PclZUyUvBjfcjIyemaxYDjudO9juQnSgj8 C8g6qJRUPMDLKOnhF8IpIMoZnJK9xwcrCt7nJRT/r2NL5fOvta9tcYGTNtQBnbta o+Cpc1ap+gzplVZ0TYYMbKrbxps/GzjkCwKFb+SGkInG/zP9JfY= =1skj -----END PGP SIGNATURE----- --/HMZzMPu6lbSf3ev-- From nobody Mon Jun 7 04:34:10 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCB53A118F for ; Mon, 7 Jun 2021 04:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 vS9iukT3f1FZ for ; Mon, 7 Jun 2021 04:34:04 -0700 (PDT) Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.23.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA70D3A1188 for ; Mon, 7 Jun 2021 04:34:03 -0700 (PDT) Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2236.outbound.protection.outlook.com [104.47.71.236]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-72-UUxqoIvsPh6NNmYAOBd2cw-1; Mon, 07 Jun 2021 21:33:59 +1000 X-MC-Unique: UUxqoIvsPh6NNmYAOBd2cw-1 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com (2603:10c6:10:10b::10) by SYBPR01MB4716.ausprd01.prod.outlook.com (2603:10c6:10:13::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.24; Mon, 7 Jun 2021 11:33:54 +0000 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::9965:92dd:f5b:87a7]) by SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::9965:92dd:f5b:87a7%6]) with mapi id 15.20.4195.030; Mon, 7 Jun 2021 11:33:54 +0000 From: Peter Gutmann To: Peter Pentchev , "openpgp@ietf.org" Thread-Topic: [openpgp] v5 in the crypto-refresh draft Thread-Index: AQHXWQzuzdssG/TtVk6GhEyMb/dWfKsIWYUAgAACZACAABPjDQ== Date: Mon, 7 Jun 2021 11:33:54 +0000 Message-ID: References: <87lf7q6sh0.fsf@fifthhorseman.net> <2e2495e8-6f4c-f842-3886-61cd696a6483@gmail.com>, In-Reply-To: Accept-Language: en-NZ, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [14.1.76.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d18c4939-bb41-48e0-e3dc-08d929a8218f x-ms-traffictypediagnostic: SYBPR01MB4716: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: IVT1jj4DfbNpRZ85MaKjGuHE6jFRla/FB/pfhkjToHfA+cmnz+ecFM8ahC1swrPoIrwBlJbvBmcFZL4JSxqiKn5OHeqVpAFQRhKRN4emeIscN+biQJD8khNOb7Pt9NhuNbcIEFKTjMq65fARZtoyCf/ZvgprUZVkoP/TrhyB8BtzLadGShL+DTW+fAmLVUBWay6B9C0CSBcWjDezU940ZpY3HMiElANE5Rd6WzWDAVXo5fbiQzKVXzVtDO75DKHwGlTHpdedZ9TvBPUf9fYRh84qFupIoemSU+/jqFvO2m8B4Qy9v/OtobXDNCXmTa5aFJEMecS3tuqBNrec3PvvlCDm6BHCPexN79noNoHXOnjc298OWMqjZ3j0oNg4qQhgxLHJfYQK/8cQUUhhx25XrlxzuTfY1PlQaiLQ8xgAKOJzfmJXU3jsuuo9KZU6pSbcCiHXINg//2XHzPH6z63kcwnAdCn6+n4GqOy6pf3lp47+ZnfeOxZb/flgTyub4cZfwZGdhU9nPlFghjmgo94BHCwGm+gtgVfKXKI7n97YBlHw453yOKCr8n1KG05r6ryji6GIr0jMczXpfR6TVvAvMso0rWYbE4wmjrGRwhLmFTo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6251.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(5660300002)(122000001)(38100700002)(4744005)(186003)(55016002)(2906002)(66446008)(64756008)(66946007)(8936002)(498600001)(66556008)(110136005)(26005)(71200400001)(33656002)(86362001)(6506007)(8676002)(76116006)(66476007)(9686003)(7696005)(52536014); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?uqq46x4glzwFTx2cd+KbjLr940/SwJYSfsh9EzcgweVmomAxZXZZu2PmgI?= =?iso-8859-1?Q?92qqtQW27pQnLkz7Z7Ocle/tb+viWkAj8o2Lmq8e2amPa5gaEMXxoPjdfN?= =?iso-8859-1?Q?wtqonlQJmD/u163AI7T8n5kdKxuWMM3wbJntEsKTCJkcHqErpjvkV8DW8u?= =?iso-8859-1?Q?F49HVGQLh3hclflPDyoY5KRA60WgNQPy5D9xVHHGDdp8QiGMYa1L1BlfC8?= =?iso-8859-1?Q?a18LaOgiqTr0rfrGA87XGJeYJVc3Cqg8howWhomC6J/UuZRK+66M+Ljr12?= =?iso-8859-1?Q?JvoPb2Lljyg2mFHXu8/ZHyxMSE4rC1hQwIhaRueFxL3UoQyfAOdglaCZ5B?= =?iso-8859-1?Q?/Xk+LQk8d2D24ZWJHgqKXKpEUZV1nU4nZtk4BwvKF9G+ag2OLTQn3rWl73?= =?iso-8859-1?Q?aa50Go7a8DiEhe75iPDKdsxw1zTNFetT4HIwnYWY+xO6JdZCIAPtP6rm27?= =?iso-8859-1?Q?J5hzrb/FsL0nAZXwTQC5rm002INDGRJ8/003+ijW636eyrcb4VZRcf5SCn?= =?iso-8859-1?Q?lKU5DkFad4cCBqv7OlVYU/eS+R488QfvrTYFfV7D5pCH6EEmaiIcdZlSBe?= =?iso-8859-1?Q?wisyr6QNprIHFrkW4XboS//2JC4FaAD/b5JDOiGxRSZal198+NEluT87Jb?= =?iso-8859-1?Q?wREZPRyefe9Kwvakfjza6ji1Q9G5tp2sW+FMUg8OZ6Z6dWzvl1VZfbhD2T?= =?iso-8859-1?Q?mPjBW2UdvOasdqk3t467wuBx4ayME/nqSijx5U1+JJ08mHZvBofNq/Oe71?= =?iso-8859-1?Q?TIq6uXpchxAQRg3CiuW4sZq9b3mrTaOn1qKq0/ILlpEnzYYdhn/nTFQmC7?= =?iso-8859-1?Q?Ymbg1QOkV/hy/i0aNBa61V5w2fHDTrlO126HW+/+3bV+Gu5x7ja3+KH8Vs?= =?iso-8859-1?Q?a7mOUDX83QCbVPyVPRXXPm/1pC8ANAp0NlKWtABNV54PUG7xMlHrKP06/o?= =?iso-8859-1?Q?IeSiWQxECRu7/w3ZJGywCgk2jven6Xn2csFgMqCS01pbTI32D0Hp3k95ES?= =?iso-8859-1?Q?AZFO0MA2t5ft8cxZYDzCYj35OUaOIKQQNOpYGe+G2TtcPHyzKNEBmdEb3x?= =?iso-8859-1?Q?AFls8jaRRRaiFXsG7cfWz32rTeCCP4lA6HiNo1xLAcq86dOIrsix/kv5SM?= =?iso-8859-1?Q?wMC7WB6zR+5rUOFNCdxyX+5TsLwlSgyF1Y7OYaHaOZRT3A1duNZb6IkNFj?= =?iso-8859-1?Q?/uCAt8+fTsxj8DQ6RdQEMa3pUgRcVW905HxBuewf+RvuXDo0QNCV/NeJwj?= =?iso-8859-1?Q?ktc2oHrMX+oT1v8RRhkJVBVmDdc+LHLihzFVkgqD/H+RPJw780HL3lTBiN?= =?iso-8859-1?Q?02vc/s8pmKTGfYetKuiAZyI5mAbi7HfqGuGNeSH52lBiHt0=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6251.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d18c4939-bb41-48e0-e3dc-08d929a8218f X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2021 11:33:54.0623 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iH4kA+KC7WtccosUUGwCv2GNNJfzTzOZZmOOjm/JXVuWKbxr8SdztT6HmsKV1DmU4k77HqYT51VWJ1tkiTg3Xyw/SNfrM5KRTvk7yPo/jZY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYBPR01MB4716 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CAU17A13 smtp.mailfrom=pgut001@cs.auckland.ac.nz X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cs.auckland.ac.nz Content-Language: en-NZ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 11:34:09 -0000 Peter Pentchev writes:=0A=0A>Obviously not speaking for = any of the people who actually work on this, but=0A>you need to keep in min= d that the time field is defined as an *unsigned* 32-=0A>bit number, so we'= ll have another 68 years after the year 2038 to take care=0A>of that.=0A=0A= Except that time_t is signed so it's going to cause breakage if you just=0A= assign a 32-bit OpenPGP time to a 32-bit time_t. Making it 64 bits would b= oth=0Aprevent this and signal to 32-bit time_t users that they need to take= special=0Acare with time values.=0A=0APeter.=0A From nobody Mon Jun 7 04:46:31 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC5B3A3D35 for ; Mon, 7 Jun 2021 04:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 v9IIB-CkdxFy for ; Mon, 7 Jun 2021 04:46:15 -0700 (PDT) Received: from osse.kmail.bg (mx.kmail.bg [37.157.165.4]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD8E3A3253 for ; Mon, 7 Jun 2021 04:46:15 -0700 (PDT) Received: from straylight.m.ringlet.net (unknown [93.152.132.21]) by osse.kmail.bg (Postfix) with ESMTPSA id 1F098125 for ; Mon, 7 Jun 2021 14:46:12 +0300 (EEST) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 6200e2 by straylight.m.ringlet.net (DragonFly Mail Agent v0.13); Mon, 07 Jun 2021 14:46:11 +0300 Date: Mon, 7 Jun 2021 14:46:11 +0300 From: Peter Pentchev To: Peter Gutmann Cc: "openpgp@ietf.org" Message-ID: References: <87lf7q6sh0.fsf@fifthhorseman.net> <2e2495e8-6f4c-f842-3886-61cd696a6483@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6eGISLx4tBDKXnbz" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 11:46:30 -0000 --6eGISLx4tBDKXnbz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 07, 2021 at 11:33:54AM +0000, Peter Gutmann wrote: > Peter Pentchev writes: >=20 > >Obviously not speaking for any of the people who actually work on this, = but > >you need to keep in mind that the time field is defined as an *unsigned*= 32- > >bit number, so we'll have another 68 years after the year 2038 to take c= are > >of that. >=20 > Except that time_t is signed so it's going to cause breakage if you just > assign a 32-bit OpenPGP time to a 32-bit time_t. Making it 64 bits would= both > prevent this and signal to 32-bit time_t users that they need to take spe= cial > care with time values. Well, if any implementation still uses a signed 32-bit time_t C type in the year 2038, it will not be able to do anything anyway. ICBW, but is the point of the standard not to define the wire format, and not implementation-specific details? An unsigned 32-bit value for the wire format should be fine for this century. But maybe I'll just shut up and let the people who have already discussed modifications to the standard (like you, so yeah, sorry) say whether anybody has ever raised this before and whether it has been discussed. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@debian.org pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --6eGISLx4tBDKXnbz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAmC+Bv8ACgkQZR7vsCUn 3xMOFg/9E0lIH2BpME6Ta4fU/JMctFI9KjIz88mesgQoJw8TxW26J69cYfAkp+FN mvI5CNaSXgy2vQxnec7ZmvgufqLWejlZ+Gm3/jESB4+IAL/ZIzFxIedElNergWwj nL1haxomY6C/FmKGczu1K6yDUh2/iEGIhgLOS/qww43fWG8vnug1bKNaZPdyJVFZ kGU4bv4NdZr4h0mlIkQFNN9QrQ1Ed2twh40u3ePKhXet8eUt1fF91Enc6xs4r6Ss 1TWYNXNprn1rxrjLh7cYeNOerVFOTQ7mSbKQeQFSrYcCxwS8dOMKI2ZJRu6+X7tq +0urz2a1txg+HJ+iL2iiBcfoaGYnFDamlIqOkdbNXbKzp0h0BHZEghxkmBy2QesZ sMoszvohJRiRNz0WJJCZ+Pl+41Zjk46cnxPqFyL+7bknxgs9sBKiygpxd3p+QAT0 rct23ZVU32LU87kqVh/CY+zrYSd8Ek20EcXNi70bo7Ptex2cd2OloeRUjr7hAIfx p2dGzjWW34aDmc5bG7EiLsT4shaMSVqZqZw+DVnBnIwt5UivcbugYs+LAR7CpJjR w5zLUZIyW5pOsyOSHqbu286TDVPVN2XJdJtExmMkwb47wxMWwBKDXNz4O3/qOIfC oqcjG0he9e4SgJv3kIMA+JMbTM0B8e78dy3m7j+QTr0/6e7TV38= =uqeU -----END PGP SIGNATURE----- --6eGISLx4tBDKXnbz-- From nobody Mon Jun 7 05:24:00 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34C33A138E for ; Mon, 7 Jun 2021 05:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 fu4F0lrLwQHS for ; Mon, 7 Jun 2021 05:23:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE3543A137D for ; Mon, 7 Jun 2021 05:23:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6D31038D4D; Mon, 7 Jun 2021 08:24:31 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nK38MPasXujx; Mon, 7 Jun 2021 08:24:26 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7DE5338D4C; Mon, 7 Jun 2021 08:24:26 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 67F9D5E6; Mon, 7 Jun 2021 08:23:46 -0400 (EDT) From: Michael Richardson To: Daniel Kahn Gillmor cc: openpgp@ietf.org In-Reply-To: <87mts3qbpn.fsf@fifthhorseman.net> References: <87lf7q6sh0.fsf@fifthhorseman.net> <376548.1622830236@dooku> <87v96sqke0.fsf@fifthhorseman.net> <14974.1622924947@localhost> <87mts3qbpn.fsf@fifthhorseman.net> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 12:23:59 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Daniel Kahn Gillmor wrote: > Each "key signature" (certification) is its own OpenPGP packet, right? > and the context we're talking about here is a hash context that is us= ed > to calculate a key signature. yes, but I'm assuming that we might sign these new keys using legacy signat= ures. (and vv) >> A v5-capable tool, which does not speak these new formats can still = process >> the packets. It could also verify that these large keys are signed = by our >> legacy algorithms. > yes, i agree with this, though it is not "skipping over" -- it's > "preparing for certifications of larger keys". Agreed. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmC+D9IACgkQgItw+93Q 3WX7nQf/eSEb7xv8D9P8ai9aZvZ5RRo1nXuhuEA3x/Hg1acdocPvqELv9+f/2F11 IbwYeD0ppZnykXusMKj5nd5zOcRVQBOVneyQnEu+teDvktoJAvLxRo1mVrh1PASv 5v0yFtP0YGDkGOqpb4zSZ7m5UF2HhpRvm/ZcznQghgZ2FSAoDlVXbDb+hz+glCZ5 y5JDuLayNBextzrM5pYD0QVHwxDXRjjjWenZ5CYhjKxHo/GVRd5SOKfX0IplW1SJ KMHUlWbE516+KxmLLybvojBIIda3H1GkHZaPiGXReyalFcvfJcm2CqmaNh4ifPuj hGL2PULfvDCL36OCMAdorkv8S32RoQ== =2shV -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 7 06:42:12 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59C73A16AD for ; Mon, 7 Jun 2021 06:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 7qB-JmZ2j52d for ; Mon, 7 Jun 2021 06:41:56 -0700 (PDT) Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.23.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19BBA3A16E0 for ; Mon, 7 Jun 2021 06:41:55 -0700 (PDT) Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2177.outbound.protection.outlook.com [104.47.71.177]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-74-cOZklx7IPdaElRy0TDuwTw-1; Mon, 07 Jun 2021 23:41:47 +1000 X-MC-Unique: cOZklx7IPdaElRy0TDuwTw-1 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com (2603:10c6:10:10b::10) by SY4PR01MB6315.ausprd01.prod.outlook.com (2603:10c6:10:10f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.22; Mon, 7 Jun 2021 13:41:41 +0000 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::9965:92dd:f5b:87a7]) by SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::9965:92dd:f5b:87a7%6]) with mapi id 15.20.4195.030; Mon, 7 Jun 2021 13:41:41 +0000 From: Peter Gutmann To: Paul Wouters CC: "openpgp@ietf.org" Thread-Topic: [openpgp] v5 in the crypto-refresh draft Thread-Index: AQHXWqjxZgm3Nb8iZ0mMkTayPQSTdKsHHHeAgAFzsxU= Date: Mon, 7 Jun 2021 13:41:41 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-NZ, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [14.1.76.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 07275bf4-7b1e-483c-e882-08d929b9fb62 x-ms-traffictypediagnostic: SY4PR01MB6315: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: BbWi4d82NiO46MaH0Y7Y3ArshS+SvyNVRDEkdye/8NcuOt+BlUiEt/DHy3gcLrnEpSMW9vuoVkC/976obj6faAXqS8/7zEYDUpLWuDFgPTbf3RTh+x2AMSGJ64tOLXEkfWaVjtkV2TVcRHvuSr40iiHuVIvr6tMnOtwHoGWCVyfchN4GSfNyscIegr45g4yX+hXgiOmt1BBzclmpf4IVa8f9AiHUOnSjOrXvpYUA1BsuGJS0KW7kMOcuW2d7AUlFs9CrfmaYsj88jLtilnwUeYXv/d6dx8kcjbXYgwNqS9774xSoAWk1tDHSCjNgpFtok53XPtXAbBxDymfNFH8a+tW8GPVLMCCZyb/FGi3t7qWo9tdaqKFx4UP91Fy1V7LKDaSytY1U6P31k0By3ioR1DmXGnB8miydEkt1ulD6cJXxzSthuFrK68I5y8ejDMyft2FhTNSaFZKzzIOaZSHODdIgcX4OZ1i75sVAChb8UlCecBaU4ZH3jMsvYouaqRnVChu5sYUlPvrhf1mfkBaRCnjDi6aZprXsuf7qsCWZPL+680GOOLH5xaf/1ZYVP+mlzM0tiwDSyn+HeT7p72MnLofWFUO6J5oP38coaFt2w0g= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6251.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(9686003)(33656002)(4326008)(52536014)(55016002)(498600001)(2906002)(86362001)(186003)(7696005)(8936002)(26005)(71200400001)(6506007)(8676002)(5660300002)(66476007)(66946007)(66556008)(64756008)(122000001)(38100700002)(66446008)(4744005)(76116006)(6916009); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?HG++cp584ZsbBTwSOwy0VJFRJNYyNgEhDkIsl5iDzCKkY/WPW84VB6ncXd?= =?iso-8859-1?Q?wUGNXeVc4D2DFTgCXctRxsLkMwnH6BvDFgCxUngIHai6yS4E387ELns3Cj?= =?iso-8859-1?Q?ZWnWXCResQY0CWMUhOV3kePM7qchWCuJcdpCQDfHk+tQ8PjJ8zSmxZTyBf?= =?iso-8859-1?Q?XMkvu8jUd3wHgL+1xPC498IXhr+dwma/CKBH3hjH3arnRAMKKcG2Scjyey?= =?iso-8859-1?Q?GJvnN5TWLzDe83YNiaJmm1ZbHddcvgv9+hnw+FpzpkQlU+xzA2RL/7BQfO?= =?iso-8859-1?Q?rdKqb0hCttKhQCg2gnx2ExEsrOYpDSR66UekEPOItIxsUL233+WVSM1bPY?= =?iso-8859-1?Q?7GuBJY6IJ9p/qX7Idp/a+EiUuADqtTfQVABkXV7NehSnb6vBmd3/4XCPQw?= =?iso-8859-1?Q?QNZ5DXxduICFl8PGgR1iQpsVyiC4fwBxR663NvB8cDEm9HA0hyWTBNO7m1?= =?iso-8859-1?Q?61yKJWUTXovJi1+2FYqcugLANftXM1SV0J95RHLOD5L24qfr0utQACU6C8?= =?iso-8859-1?Q?NcTp206lbZwOEvDEJBH+tDrFRWv8ngeic/lE0s4T9zY50o4DAioQZ2e7Qx?= =?iso-8859-1?Q?xY2ZU4GObqLvU21prXgbpnyVDBJFWZqtRytVHDdrIC8NjyL+GufVbkATIH?= =?iso-8859-1?Q?hqzGxo4EG5mcAHOj73xn7i6cNL0gYvb/LPwsZyJantN8I9EfDwAxrSZltY?= =?iso-8859-1?Q?JnTEHHpvbCKibUC2UQYdk86h624cFx87i1vwR/bPAf6C1UzCxi2GhWqRNw?= =?iso-8859-1?Q?pzUY02TU0gfofFuiiftVNI8Ds/QU0L7KOgDmbvPkbozmedpt5p7XsvFOoW?= =?iso-8859-1?Q?PFUImcs0WpRRRZg9DFMjnhI1JMHAPJXqCn4g4sQ64W8h8R2I2hrAB5L4Kd?= =?iso-8859-1?Q?IFyYTQK/S7BAk5x5aqA1H/9W1JBqB9p6KhZKYdFHtO0DbDFMzAzJubQKgl?= =?iso-8859-1?Q?xFtw3MLWqC9ceyNwL73fZIeb6sIqG7VfnrN6Aber0BZxJmdpuON9eHNsIT?= =?iso-8859-1?Q?CrTv9zlSePOA8ZVNktUcvCNBXsQ+FOtOWm0BisWMDIciFsDM4U0oGHf+B4?= =?iso-8859-1?Q?mY6AtWRtjfWZoSpC0aQSvsacIPt8VX/V2wm9mEieHIInrhvQ+cAdF4wV+4?= =?iso-8859-1?Q?8tHJ/R7U8GTZxvnqZMjufRlTOikL5NU+ARyp261pxYeeT/Bol5pAX6Jk2a?= =?iso-8859-1?Q?lSuuLmF9G2t6bfZJg9BaX02FVFSGQUMbSrMno/St8AjMhjoaSShwnNnDy/?= =?iso-8859-1?Q?i5SicRgdFZmov8sZKn3JBrPeEEh6663Gpq9+IYauGd0z24Tiil3hzb/jBi?= =?iso-8859-1?Q?CqGKeaoXOfMn4BsHvkrDyGL8sxsDzKgE4upBDdm1FWVI8ck=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6251.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 07275bf4-7b1e-483c-e882-08d929b9fb62 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2021 13:41:41.0319 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2jE4LvKQh6yku+K9PB8JW3fljlUzsWbuSdBalwsweYUEpr1LSIv0GoD8PB49UT9pEyD/1iFyXBMQPiSpxVTYaxw210HAz11rVe9wI9oFt6k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY4PR01MB6315 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CAU17A13 smtp.mailfrom=pgut001@cs.auckland.ac.nz X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cs.auckland.ac.nz Content-Language: en-NZ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 13:42:11 -0000 Paul Wouters writes:=0A=0A>We are happy to accept such pro= posed text, please send it to the list :)=0A=0AWell, if I write it people m= ay be less happy with the text :-). OK, how=0Aabout, after the paragraph "= Note that it is possible for there to be=0Acollisions of Key IDs", add:=0A= =0A-- Snip --=0A=0AThere are no cryptographic issues introduced by this sin= ce the fingerprint is=0Amerely a fixed-length opaque value used to identify= the variable-length=0Astructured data that makes up a public key. In part= icular the move to SHA-256=0Afor V5 fingerprints was made not to address an= y cryptographic vulnerability=0Abut to avoid the perception that something = insecure might be happening due to=0Athe use of SHA-1.=0A=0A-- Snip --=0A= =0APeter. From nobody Mon Jun 7 07:01:30 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE033A1776 for ; Mon, 7 Jun 2021 07:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=GECb1M8f; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=pBc9iEvq 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 78ygnAxvufae for ; Mon, 7 Jun 2021 07:01:23 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A84B3A177A for ; Mon, 7 Jun 2021 07:01:23 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1623074481; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=VwT1JYg4rD+EoPb9pSbRQ+m/SGZ0o1CpISe5w3jl2gQ=; b=GECb1M8fGI2GRpMjYkSfldzCSNCCwiZN7nyY1lX4L5AIfGgeSj+gEbfGroM6LGV4sMBc4 zs/remUsQCIkpcsAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1623074481; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=VwT1JYg4rD+EoPb9pSbRQ+m/SGZ0o1CpISe5w3jl2gQ=; b=pBc9iEvqY6jQUj99E/1zMDmyEviYyUtL5S+8Kyjc+ePURipruvnRIPK/BxdMYA7jBoWnK PwpAXpXFZMuDL9zfYOvO+7juexJBibAtWChBaimKTwpJ6GVMU0jtoTdb9uWyU7c/DMjED4j Hyu6NiZJGAJBAKeRiFFgP+RE6IElFDXPM4DWre107oUwNm5LTKJjYOb+BPOL53PTiiplhH8 MXnNsIaase7kG7GwsOFUpkG81s8/UQhyNilSeemJh61Nv9rSNxuS/U85CV7AG1JVZPxC380 33PCRGNacv+tqx4vlFqlrPoUKU+wb4x6pz4Lv+2eYwfWjyOlM+Qchl1bIGvA== Received: from fifthhorseman.net (ip68-0-212-178.ri.ri.cox.net [68.0.212.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 6EF55F9A6 for ; Mon, 7 Jun 2021 10:01:21 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 004FE2049A; Mon, 7 Jun 2021 09:46:23 -0400 (EDT) From: Daniel Kahn Gillmor To: openpgp@ietf.org In-Reply-To: References: <87lf7q6sh0.fsf@fifthhorseman.net> <2e2495e8-6f4c-f842-3886-61cd696a6483@gmail.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Mon, 07 Jun 2021 09:46:20 -0400 Message-ID: <87eeddrdn7.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 14:01:29 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon 2021-06-07 14:46:11 +0300, Peter Pentchev wrote: > On Mon, Jun 07, 2021 at 11:33:54AM +0000, Peter Gutmann wrote: >> Peter Pentchev writes: >>=20 >> >Obviously not speaking for any of the people who actually work on this,= but >> >you need to keep in mind that the time field is defined as an *unsigned= * 32- >> >bit number, so we'll have another 68 years after the year 2038 to take = care >> >of that. >>=20 >> Except that time_t is signed so it's going to cause breakage if you just >> assign a 32-bit OpenPGP time to a 32-bit time_t. Making it 64 bits woul= d both >> prevent this and signal to 32-bit time_t users that they need to take sp= ecial >> care with time values. > > Well, if any implementation still uses a signed 32-bit time_t C type in > the year 2038, it will not be able to do anything anyway. ICBW, but is > the point of the standard not to define the wire format, and not > implementation-specific details? An unsigned 32-bit value for the wire > format should be fine for this century. The standard is good until 2106, barring implementation failures like what you describe. I've opened https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/-/issues= /55 to suggest some possible tests that would try to identify such implementation failures. > But maybe I'll just shut up and let the people who have already > discussed modifications to the standard (like you, so yeah, sorry) > say whether anybody has ever raised this before and whether it has been > discussed. this came up back in 2016 here: https://mailarchive.ietf.org/arch/msg/openpgp/cb32QpGl5-PP02s_dYsTkl3rV= K0/ At that time, there was no clear consensus, and (different) reasonable people advocated for: - leaving the timestamps in the standard untouched - using a 40-bit timestamp (measured in seconds since the epoch) - using a signed 64-bit timestamp (measured in seconds since the epoch) - using a signed 64-bit timestamp (measured in 100ns units since the epoch) - using ISO 8601 timestamp representations I'd prefer to not focus on that question right now: aside from not having consensus, i'd argue it's outside the scope of our current charter, which is for cryptographic refresh, and we're behind on getting the crypto refresh done. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYL4jLgAKCRA+nXFzcd5W XD8bAP9V3r+vy+C83UwngJ6vhPOzfhzpSh68AsshDHDiqpWjgAD+MzhVqaLf+M0n hVBcaBBJOhSzJp8toiqGeli3IW6x0wQ= =qCc1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 7 08:59:14 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC723A1AF1 for ; Mon, 7 Jun 2021 08:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=sFeHzdu1; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=gEOT89c7 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 u09Pyc3MdurT for ; Mon, 7 Jun 2021 08:59:07 -0700 (PDT) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8E33A1AC7 for ; Mon, 7 Jun 2021 08:59:07 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1623081546; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=d54IElywdUKx332AwVVgXOJEQEbZ7DZVOU9lWFpviok=; b=sFeHzdu1rQFdCR33X8kOTPL9gcwwRcLwfoC1yq2f9xtjQIvuK8VMRDiUFN/S2K/lDconZ kNj8+P7eooG39QGBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1623081546; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=d54IElywdUKx332AwVVgXOJEQEbZ7DZVOU9lWFpviok=; b=gEOT89c7jJhEwZULmkdK1f2pofeovHqWjUeEuMvClNUYF34g156Nvn1iKaLqDbawTU203 Z9pIVT6Q/oabNBwFXGQOiyy40dMY3lBvkVCO6wunVyyMDwaN8pxSbWcdLwBmuYXuspKhsVG sr+cQ4g3CGu6W61TI4fjm3Tpvy2T4NBrr+FFHPCYybeQAHJPlJCb0A2XMkFqUuRKBhikrNh rr1oQAn/dgvDE5jLS2rnahvljq3V1ZfQiw1FeNZeO2WrxzTJ0Y30ec5bVjbqXDsZpLTCTUc 5t6F9JhqI7m6Ndcf+MC7wMVEU+9QFWhQzuSe6TzTEy22AUe+HE7G1xvNhpww== Received: from fifthhorseman.net (ip68-0-212-178.ri.ri.cox.net [68.0.212.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 371B1F9A6 for ; Mon, 7 Jun 2021 11:59:06 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 63F9F20481; Mon, 7 Jun 2021 10:34:04 -0400 (EDT) From: Daniel Kahn Gillmor To: IETF OpenPGP WG In-Reply-To: <30581.1622914332@localhost> References: <20210602230847.3593022-1-dkg@fifthhorseman.net> <30581.1622914332@localhost> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Mon, 07 Jun 2021 10:34:01 -0400 Message-ID: <877dj5rbfq.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] WIP: bind wire format representations to specific pubkey algorithms X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 15:59:13 -0000 --=-=-= Content-Type: text/plain On Sat 2021-06-05 13:32:12 -0400, Michael Richardson wrote: > I don't think that it's right to think of post-quantum as being a > crypto-refresh. I agree that PQ is probably out of scope for the current draft. > That is, replacement of one set of algorithms with another. > Rather, I think it's better to try to think about this as being multiple > algorithms present at the same time. This also seems sensible to me, and i'd hope if the WG completes the crypto-refresh draft and wants to continue working together, i'd hope some folks with good PQ ideas (like the above) would suggest wording for an eventual recharter. But we need to get the crypto-refresh draft out the door first. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYL4uWwAKCRA+nXFzcd5W XJsrAQDzyvRyqMyKYTOYbnqbNeZDvv8cNS5BPDh0taj6N3fZBwD+KNqGgEh3yzRM jDbLSoDPHKt81g4Ups0vol0N7nuehgI= =bwZT -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 7 11:46:11 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A93C3A4155 for ; Mon, 7 Jun 2021 11:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 OkL-oN9a6uzQ for ; Mon, 7 Jun 2021 11:46:04 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 144573A414D for ; Mon, 7 Jun 2021 11:46:03 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4FzMl80mbfzKFr; Mon, 7 Jun 2021 20:45:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1623091556; bh=fi63byCiqTRVQeBI9fnwTm/tsFb5wdb4V9KKMAE9k64=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kAqjpCcq4NjhR99jgTIaUjFTpolNiLzPV/FHYNGf5hO38Ql3CDzjJ+WrjpVZmDcVP dPv9mVwJphcb11HtI2mvR/91TSnZs9ow81mKFmWlz1QH1uCTuuDSFzk3xRiZaRCjAM NmjGXLcKd+ECmxogIZaY0n9I4Ucr/R2QBp0DlO3s= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id BkkjgXDLEXJD; Mon, 7 Jun 2021 20:45:55 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 7 Jun 2021 20:45:55 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C99CE7E797; Mon, 7 Jun 2021 14:45:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C307C7E796; Mon, 7 Jun 2021 14:45:53 -0400 (EDT) Date: Mon, 7 Jun 2021 14:45:53 -0400 (EDT) From: Paul Wouters To: Peter Gutmann cc: "openpgp@ietf.org" In-Reply-To: Message-ID: <3dcadec1-6ff0-911a-ed2-58534d3a2f6@nohats.ca> References: , MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 18:46:09 -0000 On Mon, 7 Jun 2021, Peter Gutmann wrote: >> We are happy to accept such proposed text, please send it to the list :) > > Well, if I write it people may be less happy with the text :-). OK, how > about, after the paragraph "Note that it is possible for there to be > collisions of Key IDs", add: Thanks :) > -- Snip -- > > There are no cryptographic issues introduced by this since the fingerprint is > merely a fixed-length opaque value used to identify the variable-length > structured data that makes up a public key. In particular the move to SHA-256 > for V5 fingerprints was made not to address any cryptographic vulnerability > but to avoid the perception that something insecure might be happening due to > the use of SHA-1. > > -- Snip -- With no hats on, I would probably change the latter bit to: In particular the move to SHA-256 for V5 fingerprints was not made to address any cryptographic vulnerability, but was made to follow the generic guidelines of the cryptograhic community to sunset the use of SHA-1. This would then also capture other reasons than the one you mention, such as possible unavailability in crypto libaries or runtime modes (FIPS) etc etc. Paul From nobody Tue Jun 8 00:17:31 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1113A2596 for ; Tue, 8 Jun 2021 00:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 KtO5-wicVo0L for ; Tue, 8 Jun 2021 00:17:25 -0700 (PDT) Received: from harrington.uberspace.de (harrington.uberspace.de [185.26.156.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6691F3A2580 for ; Tue, 8 Jun 2021 00:17:24 -0700 (PDT) Received: (qmail 5426 invoked from network); 8 Jun 2021 07:17:15 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by harrington.uberspace.de with SMTP; 8 Jun 2021 07:17:15 -0000 From: Justus Winter To: Daniel Kahn Gillmor Cc: openpgp@ietf.org In-Reply-To: <87lf7q6sh0.fsf@fifthhorseman.net> References: <87lf7q6sh0.fsf@fifthhorseman.net> Date: Tue, 08 Jun 2021 09:17:14 +0200 Message-ID: <874ke8x1tx.fsf@europ.lan> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 07:17:31 -0000 --=-=-= Content-Type: text/plain Daniel Kahn Gillmor writes: > Possible Outcomes > ----------------- > > a) WG consensus that all of these are appropriate: keep them as-is > > b) WG consensus that some of them are misfeatures, or otherwise > inappropriate for the crypto-refresh: drop the unwanted parts from > the specification of v5. > > c) WG consensus that some of them are misfeatures but due to > pre-standardization deployment that produced existing artifacts, we > can't claw them back: call the new OpenPGP version "v6" and just > skip over v5 (like IP!) > > Note that for both (b) and (c) it's possible that the new version is > basically just "v4 but with a SHA256 fingerprint instead of SHA1". I > don't think that's necessarily a bad outcome! My preferred outcome is b, but c may be more practical. We (Sequoia) have partially implemented proposed changes from RFC4880bis, but starting with our first stable release we decided not to emit any artifacts that use new packet versions. Justus --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFLBAEBCAA1FiEEJWpOVeSnLZetJGjniNx+MzhfeR0FAmC/GXoXHGp1c3R1c0Bz ZXF1b2lhLXBncC5vcmcACgkQiNx+MzhfeR10owgArcacQayzhTJNswLO3Rhrgoky v7V/BgIjBXdNewKdk2Z5Ctlxtsydap+Xe4+z26bStTIfdZlsLuxap0elpY20mfbN hHyau6Z7VeXM0HOn4TedpRIy1llyOapnPqLOEDUpD7/fjMmQ2w+jMudvh18OPzYU N6qGQMIpLncpawDNKs9/o6wHMoEtTN93GgW1lgItuE7pdPoH2KvYmysqOwVxRV1D 05loaMHcN1P+6BC11gSMPC9XjxcPoJHn7gpx2FoiIZjSTZGIu3YSuh/D8IloTaUc kfROHjnPQ4f2QJseqGfVYg8Ph/tIFSUkF2R9+Jt/mghoXb7VBcy3dzNGvs4Qdw== =nn2z -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 8 23:51:40 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213BB3A12D0 for ; Tue, 8 Jun 2021 23:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 VW_Sj4uMz6kh for ; Tue, 8 Jun 2021 23:51:34 -0700 (PDT) Received: from harrington.uberspace.de (harrington.uberspace.de [185.26.156.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 977163A12CD for ; Tue, 8 Jun 2021 23:51:32 -0700 (PDT) Received: (qmail 18450 invoked from network); 9 Jun 2021 06:51:26 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by harrington.uberspace.de with SMTP; 9 Jun 2021 06:51:26 -0000 From: Justus Winter To: Daniel Kahn Gillmor , Florian Weimer Cc: IETF OpenPGP WG In-Reply-To: <87k0n7qb7c.fsf@fifthhorseman.net> References: <20210602230847.3593022-1-dkg@fifthhorseman.net> <87eedg9u4d.fsf@mid.deneb.enyo.de> <871r9grzeb.fsf@fifthhorseman.net> <871r9g9nmr.fsf@mid.deneb.enyo.de> <87k0n7qb7c.fsf@fifthhorseman.net> Date: Wed, 09 Jun 2021 08:51:24 +0200 Message-ID: <87y2bjv8cz.fsf@europ.lan> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] WIP: bind wire format representations to specific pubkey algorithms X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 06:51:39 -0000 --=-=-= Content-Type: text/plain Daniel Kahn Gillmor writes: > On Sat 2021-06-05 20:23:24 +0200, Florian Weimer wrote: >> I guess every implementor who tries to layer OpenPGP on top of an >> existing PKCS#1 implementation will eventually learn about this, but I >> suspect I'm not the only one who was surprised by this. > > Good call, Florian. Can you propose language that would clarify this in > the current draft as implementation guidance? seems like we might want > guidance for both signature generation and verification. > > I've opened a request for a new test in the OpenPGP interoperability > test suite to see whether any of the tested implementations can handle > this: > > https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/-/issues/54 Seems all implementations handle this just fine: https://tests.sequoia-pgp.org/#Improbably_short_RSA_signatures I also tested signatures that are not a multiple of 8 bits, same picture. Justus --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFLBAEBCAA1FiEEJWpOVeSnLZetJGjniNx+MzhfeR0FAmDAZOwXHGp1c3R1c0Bz ZXF1b2lhLXBncC5vcmcACgkQiNx+MzhfeR1rzwf+NMqPw4dYRFCN8Fw5ZGlZ9c0N oHZplikE4G/9UqHoisjWPg1mwWpbol2VsxenfsbGgSWOH2pS4rwCCO+ylXP5h4YV ep2RM2hu6g4bMgix+Yju/wnn+8rZ+i6Vv7o2msoqJ5UWi72j1x8DQX2Y8rivVft8 quI3FsAXaOUEABb5cD9+uBoDPIFcAYIqGdbgZfzq3h3KukJAz86pLIxGheH8FtCw Z6ovoqYx8sYJJkSQokW60TkHuYlvRp4kUGCoF/pzKmypL8ylM+bhqFdwZ1dHBtBL U4oy/9z825+hSAKOYZZNpJqesJ4TMnONkheVzEIe1HzbnS7DEQKpulN7Oq/fVg== =7zHf -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 9 15:29:04 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA9C3A28BA for ; Wed, 9 Jun 2021 15:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=RT8og1Lh; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=UFObsZSL 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 2jf9YigADzVZ for ; Wed, 9 Jun 2021 15:28:55 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D56493A28B8 for ; Wed, 9 Jun 2021 15:28:54 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1623277732; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=PC5v5nPG7sC0mi9HRIHdVbgXXAdwZG1nf0dE3oEyePc=; b=RT8og1LhJIizA9uy3BRnP9ESaFOQbHq48/0uzJvKLxTWVmbLow3qCk5GIhYlWu8AsLwWz C4JTOmPuclypkEZAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1623277732; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=PC5v5nPG7sC0mi9HRIHdVbgXXAdwZG1nf0dE3oEyePc=; b=UFObsZSLrKPIKdYNQJSb9IyYlQwhvn0aJp80eU09CvP84/I2DRcWg+lSF7BT5NAQOXtbh oPrOgukwdfyu+QlvpCxUBFEyoBlh6RvUWKGGzdbFChlpTvHLrhpinnga7aG6bgzbOb1+n5o nGIqIMCL4Tn9KEt9izh5c6LAQ9nuyUBudMhGWb1HFDnV16j6IklAMSPRRsC+Rljr+8uWnPK Ps4JUsFlyPlgZFHgLDGTWqtWd2eJDTSWPPHE7d/OHutaC6IvAq1CoT9I1iX4tBIkJlX/kcu RsvSa1vLVWvDe8/Ywtr25PnptqOCQBQYDlBZbdiw+vA6CTun9uFYUPrEuL9g== Received: from fifthhorseman.net (ip68-0-212-178.ri.ri.cox.net [68.0.212.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 4A518F9A6; Wed, 9 Jun 2021 18:28:51 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id D9F802030E; Wed, 9 Jun 2021 15:09:47 -0400 (EDT) From: Daniel Kahn Gillmor To: Paul Wouters , Peter Gutmann Cc: "openpgp@ietf.org" In-Reply-To: <3dcadec1-6ff0-911a-ed2-58534d3a2f6@nohats.ca> References: <3dcadec1-6ff0-911a-ed2-58534d3a2f6@nohats.ca> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Wed, 09 Jun 2021 15:09:46 -0400 Message-ID: <87im2mq2h1.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 22:29:02 -0000 --=-=-= Content-Type: text/plain Thanks for raising this concern, and for proposing text, Peter. While the standard itself actually uses fingerprints and keys rarely (only in the "issuer", "issuer fingerprint" and "revocation key" subpackets), I think for this discussion we should remember the most sensitive context for use of key IDs and fingerprints, which i'll call the "comparison-verification" practice: Key ID or fingerprint comparison has been recommended in the past by the OpenPGP community as a reasonable way that one communications peer can confirm that they have the "right key". I grant that comparison-verification is not specified in RFC 4880, but we can't pretend it doesn't happen either. (the fact that people are not actually very good at performing comparison-verification is itself a separate issue) Peter Gutmann wrote: >> There are no cryptographic issues introduced by this I'm concerned about the unclear antecedent to "this" here. It might be read as saying that there are no cryptographic issues introduced by 64-bit key ID collisions, but i think it's talking only about 160-bit fingerprint collisions. There may well be cryptographic risks for any user or implementation that uses comparison-verification based on key IDs specifically -- it's downright cheap for a third party to generate a colliding 32-bit key ID (cf evil-32), and within plausibility for a third party to generate a colliding 64-bit key ID, even assuming a theoretically perfect hash function (particularly if any one of a pool of potential keys can be targeted: the larger the pool, the faster the brute-force attack). >> since the fingerprint is merely a fixed-length opaque value used to >> identify the variable-length structured data that makes up a public >> key. I don't think this sentence characterizes the entire argument. If the fingerprint were calculated over any *externally-supplied* data in addition to the data generated by the keyholder, it *would* be a cryptographic issue, because the provider of that external data might be able to manipulate the fingerprint, which could then be used to break any comparison-verification practice that uses full fingerprints. The fact that the fingerprint is calculated over data that is intended to be supplied uniquely by the keyholder is what makes SHA-1's weak collision-resistance a non-issue in this context. >> In particular the move to SHA-256 for V5 fingerprints was made not to >> address any cryptographic vulnerability but to avoid the perception >> that something insecure might be happening due to the use of SHA-1. On Mon 2021-06-07 14:45:53 -0400, Paul Wouters wrote: > With no hats on, I would probably change the latter bit to: > > In particular the move to SHA-256 for V5 fingerprints was not made to address > any cryptographic vulnerability, but was made to follow the generic > guidelines of the cryptograhic community to sunset the use of SHA-1. I'm fine with either of these two framings, with a slight preference for Paul's text as it captures a bit more of the shifting landscape. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYMER+wAKCRA+nXFzcd5W XP1+AP4m3bGlXXgO5pYFe1StQEm0Y9SIDW6QiM+NgdumIHpOhgEAj++QqRRLdf0Y W3cdTrfZql6zcGGun+XVUvtGb7EE3go= =LEL/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 9 22:40:51 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD0C3A3544 for ; Wed, 9 Jun 2021 22:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_BAD_THREAD_QP_64=0.998, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 fj8VkwBlkQUS for ; Wed, 9 Jun 2021 22:40:43 -0700 (PDT) Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.23.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C25F3A3542 for ; Wed, 9 Jun 2021 22:40:42 -0700 (PDT) Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2241.outbound.protection.outlook.com [104.47.71.241]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-34-ahOt-nfGMkatbfRgr8MCTw-1; Thu, 10 Jun 2021 15:40:38 +1000 X-MC-Unique: ahOt-nfGMkatbfRgr8MCTw-1 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com (2603:10c6:10:10b::10) by SYBPR01MB6159.ausprd01.prod.outlook.com (2603:10c6:10:ed::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.21; Thu, 10 Jun 2021 05:40:35 +0000 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::51a7:5858:c7ef:880f]) by SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::51a7:5858:c7ef:880f%5]) with mapi id 15.20.4219.022; Thu, 10 Jun 2021 05:40:34 +0000 From: Peter Gutmann To: Daniel Kahn Gillmor , Paul Wouters CC: "openpgp@ietf.org" Thread-Topic: [openpgp] v5 in the crypto-refresh draft Thread-Index: AQHXXbr+7O9O+mcMl02kzvDvrO7x3Q== Date: Thu, 10 Jun 2021 05:40:34 +0000 Message-ID: Accept-Language: en-NZ, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:df0:0:2006:f15f:3abb:d8a6:7c15] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4e0f6062-f4cd-4ac6-4cf1-08d92bd244f9 x-ms-traffictypediagnostic: SYBPR01MB6159: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: BSouwBwaath063nK4GxzVKaK18q9/cB+7ekkSN4mu6PvCcJtlu3UGygkeJJxilOzkxvgiWIQSnViOs1Vbaqn95I0cDrNFzPiA74sFOFXT5U6tsWyuS7mXgjGfQaV5S80An60GEH36BfqgnbS5pnS6Dz/ailrY/cdUZRQG1uVchn/cr8asMqNdAHmMAb2g6BPDLFY1z383QE+YqivGv6T8WBldK5TOhn/shL9YzroRnHcRWuGBXqYjin4QUNP+p/tSBnRGKBqb7nzlnzkH8kk8tlzhYWO9YlId6Iy80jVGrMJ9UUC8EazNExewwKgAN+5MwklvmaX41UBM2GOEYOSvpIJ/hCg81l2Sv+moEQbrPnLmZ8PkgOS6s78c3i5fHj4CGWrYVx1lnY71LjxI5wmuNNgPRXBGExpeb0RAkFzAqPm7ekI2FSVBUCpTPEFhRVzDgiBzIG5DEqKMiTA3ogAsDYeoWQZgnuvR9JwcBjYLr0lW07oigjojl0QEmkcmey+I5PM3hPDA9ZBC6W/cGswV6alSBOa/wayGqAr1PVf9ZxllCPYCkvhbnb98Uf4x3z4FwShxJLmmXE1LQDVSZ1t1eduZD6ePQ/gtBY1bKjcomI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6251.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(39860400002)(396003)(366004)(376002)(4326008)(478600001)(8936002)(86362001)(64756008)(8676002)(66446008)(66946007)(55016002)(9686003)(66476007)(66556008)(71200400001)(76116006)(5660300002)(7696005)(52536014)(186003)(316002)(786003)(110136005)(6506007)(122000001)(83380400001)(38100700002)(33656002)(2906002); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?UQCRYf2RzekZLKxvcjueZK3tZztkB+7ZHgl9iGgTd9/4rRdDzjyECaJf1i?= =?iso-8859-1?Q?88UdaoRlSp5hok8TKLWzGHBxyqBNYBndP4NPkkX+2q555eG+GI/Sg3ZHtd?= =?iso-8859-1?Q?VVzIh8dSSc2LguYj1k9GCQStIBE90iGLcz7rZJW8tAavefxrSogfjxCxmZ?= =?iso-8859-1?Q?D6HGDovH0yPyjkpDyeGgGGeT3vJVO/pQK9y0FS6fHKT62jQ2FzPCfK+ZWK?= =?iso-8859-1?Q?EDdwLiQvL9ST9K6Qyi5ehjSeO6gXmPCVZybaCM5Xvp8rLdUU+zyUB+Idzd?= =?iso-8859-1?Q?SlcV6I3GgSy2IrGp2usPELZf7QKzZT2aQg9L1YZY/fm2REItfCou0NeXKp?= =?iso-8859-1?Q?9pRmnmQ0cKnIAcFwRoryYZtXZq/56NpB9DbQ69wDzfnAgWHeWDEBxYgtuy?= =?iso-8859-1?Q?nAmNZE/1yjQ7h60jpRcp6Sdh7Nn22pT8ZKEGH1pCNvQBIm1mh8pEYMRGc2?= =?iso-8859-1?Q?rZ3ArzP2NEpZrljT6iN/yrpjkIiHp58kEE/t649E9i08xkyYOuloS5xqDE?= =?iso-8859-1?Q?skZnFzORy+SuAazvy07hY71AelCFuXAlOzZSB6vFSkn88WpRd55nwIQJXw?= =?iso-8859-1?Q?nuo0tNqLSwFyMdN04pUXLq00y5k/rGYcAUeSsumfx+ooB2SAqpMq1mVM9K?= =?iso-8859-1?Q?ARqPR6u8m7MJ5l3P/Ry27C0BlM4V2VvKkzP7s4g+ptJBC4vt4/tvgyW/ap?= =?iso-8859-1?Q?3RbWEeegqYedSWba1EwmvwuEDTyqLXqGmZVK2paRYLh5jwj6qkHMLS4A+S?= =?iso-8859-1?Q?fmNAjv1J2g9K5vLsJkTSwtQBbdoObuA5VQX8VJ/KkKtaDeK9aA9MWdit1n?= =?iso-8859-1?Q?PzQqpUmtyKYUm15RlPHnRQKTc9AImtVETcWVJzrLibzRJz0WFYaaoISzp6?= =?iso-8859-1?Q?EtdYgFQj+IyJVF+HPqmsX0Poa+yft+6CPNoMxRSsYdqcmsPd24aWCOrchJ?= =?iso-8859-1?Q?bZb5O3CTHQ0+i7IYnzSrG2twJFcDPGDRRBHEY4yUhwcKoR9kcyPwbHIByx?= =?iso-8859-1?Q?4fNSMEtD5NtGGDc0O0vGxM7lMh9Bd34dDlhILQKgGtsUMvfzCgVyyHm57t?= =?iso-8859-1?Q?MwkDyFJWrXBhaiSxK1qxDtUWsHLFbBIePy6aYt+X3uBlQEPvWqPJhZqWl+?= =?iso-8859-1?Q?HXs9h43DP0shfY0ei5Ftzf8MLkgYYaQEGkJhSVeoIXlyH9GWaUFc32ELi7?= =?iso-8859-1?Q?lio6OT3hB8OL2+Pf0Qdn6Vo4ge2G67qZyUtJ5Tw0RNJ62zYdI2A92buBtW?= =?iso-8859-1?Q?OD/2l1MYm9msxtcAtXM/07cw9zVhH4VV41o+bWnmBEtrKOW/TQ5/XWSNZS?= =?iso-8859-1?Q?NhyqtwbKj/Z4mAtf2MQn8C1UZ+p6OyMmGndjR4QpTp0IZ4WGfjtfYt8Mf9?= =?iso-8859-1?Q?VO8IxiFCTAz2oJVr5lRUOyglP5oeR9O05L5vUabcl/DsuIUO1zNm4=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6251.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4e0f6062-f4cd-4ac6-4cf1-08d92bd244f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2021 05:40:34.3320 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KwwSYV38tHNYPo0Lknr0evCzWJVs73PWKQgIviY0xglJkQe2LYF1xCRVhWWDpahsUNzwy4iJmN++ymHQhQ5VcBXqKkKBoJqIamFZQFa18vo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYBPR01MB6159 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CAU17A13 smtp.mailfrom=pgut001@cs.auckland.ac.nz X-Mimecast-Spam-Score: 1 X-Mimecast-Originator: cs.auckland.ac.nz Content-Language: en-NZ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 05:40:50 -0000 Daniel Kahn Gillmor writes:=0A=0A>Key ID or fingerprint comparison has been= recommended in the past by the=0A>OpenPGP community as a reasonable way th= at one communications peer can=0A>confirm that they have the "right key".= =0A=0AAh, good point, so it's a human-factors thing rather than just (say) = mapping=20=0Aa signature to the key that signed it, where even if you can c= reate a=20=0Acollision to point to a different key the signature check will= still fail.=0A=0A>which i'll call the "comparison-verification" practice:= =0A=0AIs it worth mentioning this in the text? The current text just says = "this=20=0Athing is the fingerprint" with an implicit use elsewhere in the = doc of=0A"the thing used to identify which key is being used", without ment= ioning its=20=0Asecond, non-protocol use, to verify someone's key.=0A=0A(Is= this still done? When was the last time someone here attended a key=20=0A= signing party?).=0A=0A>I'm fine with either of these two framings, with a s= light preference for=0A>Paul's text as it captures a bit more of the shifti= ng landscape.=0A=0AI'm happy with Paul's text as well.=0A=0APeter. From nobody Fri Jun 18 06:29:19 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F75E3A436D for ; Fri, 18 Jun 2021 06:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cs.tcd.ie 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 gKMlwlQ-wsp9 for ; Fri, 18 Jun 2021 06:29:12 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50119.outbound.protection.outlook.com [40.107.5.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1753A436C for ; Fri, 18 Jun 2021 06:29:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DtylSTmF5lecvaPXJaHs7I0WNAu9dVjYy+476eTNHlIey6pbV/gA6164Zx4JwA2yKGNrzuEhH2MT0/kAAtx3c+t1qolltUlt0fj0Vx4Z/9tZ2Mr8vaEoKNh0LqMDT0FSrSh4SfAS5DsxRL5joG2eBmG0nbC8pxSpnwKXl57BVTBkIa4XIiLamtJha8wgzZ/D93do+hvEHwPB17oaCrX0I5pocpiJ+OyHaaAiV+HmulFqB5KnQAQ8bRUfbX7hOAgVY0CYvBQBZMJ0PXQTnzeDNIivbYit7Z6bhz9oENGTNg07R5qfe1LZkYb7+eLqwoRVhL06Nqjqal+hYLkNUN1jUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eSIXWmdDmHKAzneRj4DY4aA+m3HPCmREhJmAH/9YT6A=; b=IliwA0i1sDGO1MovFq85uXq5WMCkGddX5ko4out/r87uQWQJuvBsu7k0QAnsnRs9YCTYx2VQdUw+pWtgfEXJ+mO+N/P5qIK8u+pIqx4FAVzYsvSzzJAdLOnjcsYwIjHFAdDMCYvJbaBg9F3KV3/DdnV704uTJdtxuvxgMbtCLy+/4rOj17hiPV21DPT0yQx/eEi9zrqjzc7ksx1vFyPLNQ4Z5233JYnkNiXLpiv7OhWMiCwtu4zC9vck/NX4Gex4V30w7kuZlQcU+Vi3tMRnCecPJcKaeik4ljws9Kko3YFxMSzqECBEzGl2oYySM0C1C2PWqNUkDi28Pkw+Xgjp4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.tcd.ie; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eSIXWmdDmHKAzneRj4DY4aA+m3HPCmREhJmAH/9YT6A=; b=tr9Rr3Mc8gwgOanktMfoxJYZ2JmOn3HU4IjSFAHk8o3s64KH4GM/V2q5Db1xVlMSH6LPXOmRlySD69sN+WHzeNT8MIUvW0UxP9vlCdF8tggulYkmtxR9Ud5OLXmx/pGJfpCS+HLqHCrrPWQSS9zvIwAMuDX1SibVLkk99nC6w5kkuMaMMZRfveH3D/qi0DMmBAHsO69pyZ2BlnS2zYByIlLH2wxMrfTtMD9adZ4oaW1ZQTEPHD/4KrspYUidpDtYxeqdMqngMartOlDPXXNoTAAzB6Wi7LyQJ0yvyKzF+19Wn62X2CTuwQUlzl35Q+jiLTeB6lFWYcGfNkFlnmp8vg== Authentication-Results: fifthhorseman.net; dkim=none (message not signed) header.d=none;fifthhorseman.net; dmarc=none action=none header.from=cs.tcd.ie; Received: from DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) by DB9PR02MB6924.eurprd02.prod.outlook.com (2603:10a6:10:22f::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19; Fri, 18 Jun 2021 13:29:09 +0000 Received: from DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::9c71:9f6:9136:f849]) by DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::9c71:9f6:9136:f849%6]) with mapi id 15.20.4242.021; Fri, 18 Jun 2021 13:29:08 +0000 From: Stephen Farrell To: "openpgp@ietf.org" Cc: Daniel Kahn Gillmor Message-ID: Date: Fri, 18 Jun 2021 14:29:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kcDM1G3ezXQLA5NyJjRsXR9qUuk93XMrU" X-Originating-IP: [2001:bb6:5e5e:b458:2dc7:8519:e46b:96da] X-ClientProxiedBy: DB6P192CA0011.EURP192.PROD.OUTLOOK.COM (2603:10a6:4:b8::21) To DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2001:bb6:5e5e:b458:2dc7:8519:e46b:96da] (2001:bb6:5e5e:b458:2dc7:8519:e46b:96da) by DB6P192CA0011.EURP192.PROD.OUTLOOK.COM (2603:10a6:4:b8::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.15 via Frontend Transport; Fri, 18 Jun 2021 13:29:08 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 16ba635f-c85f-4388-ce32-08d9325d0d5f X-MS-TrafficTypeDiagnostic: DB9PR02MB6924: X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True X-Microsoft-Antispam-PRVS: X-TCD-Routed-via-EOP: Routed via EOP X-TCD-ROUTED: Passed-Transport-Routing-Rules X-MS-Oob-TLC-OOBClassifiers: OLM:3044; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JAWCl5eiXju+L1Ze1lHMpb0d71oGZic+z0BpjpAT+yoqKTxyKkA8Br+MdN/QkAfcXAMAMrXqwUqCZk+DoNY+pxLk/Y+6xOdQrpKaRIq45eVSZlI6isv/q4ic6Ywa4zwH7xh3r/O1fCQ0pMJrZ/60rgmcNOLVk2yBoa9JjYTfpI+DmT8XjyX323pg5K59lpBEYeTjxjmEt3gj/0SDBZ+Ng+ZbPUnr7nH9+0Uv9nZJI+qe+ybdYOt6saONke5eq3r40aalQFWBnF9KQudMGTNxQzAijX4jtl7FyfnS5bEcyTXwbzZzWvol9G7GB/HKsm349pj/uaBzh30Tii0h+m3M6znjAM/iZ1w3SDhLctpkqkIl2Qjr2t+yMTjc6XEPWmhHR3zIRO1ZwcUKC67k8WyQHD+hRxGRHqMD8SEc5WoZLWkOviKIcaOatzMV0DoCJTrLMxOVKX8sUlSEf0oM7qfXOvKSUrOH9rBZK8FuGgE1mdB8BE1K9DvVezngevfbFSJ4zoULVjsev7ZiSFWHHSpXUr+8GMwwKQNL4iSxZvC3PLiFE2tmHdBABR0DKMAyq+mGX1B7nBUC0LXzm3jsNTh8wIGgUGX4N3DqJjobS/5u3va3JfMKe8+lXkkvo7k+/bjisunjnISp63p42waV/9fd4jPh+8i+LmDcom5BMP5qAk8FKrRdVVFNJ8Qop2vX0Zqr X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR02MB5113.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(136003)(376002)(39860400002)(346002)(86362001)(6916009)(52116002)(5660300002)(66946007)(44832011)(2906002)(31686004)(316002)(66616009)(66556008)(786003)(235185007)(186003)(38100700002)(2616005)(6486002)(33964004)(36756003)(21480400003)(66476007)(4326008)(16526019)(31696002)(478600001)(8676002)(83380400001)(8936002)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Ri96b2tRT0hVa09iT3N5YmtwK29wMnhINDkvZW0xV1ZnMW84ZW51NzB6K3Zj?= =?utf-8?B?TVNzNE8wem5rWGhwMVJTQk9SUmNXSThZVzc1NlAxTXViSjkxakRqbmR5aW1r?= =?utf-8?B?eE8xY0dlblFqUW1lQVczbG8wbWNPNjVwVnZMbm1oNHdyTXc0V3VzQU9JM3pH?= =?utf-8?B?ZFJIcVNCNjk1U0tmd3d0UlU3a2ZmU0h5WCtGbGV1bXVrbUhzVTJydXdBZnlG?= =?utf-8?B?NGxrYVBJUmcrS2RUdUREckRyZFRkOGJqbVZaK3h1eGg5blQxQ2lmMWdQMVdT?= =?utf-8?B?MlZiYjhJWU5RTVBOZks3Z2N2bk13YmttNU1nb0ZlVGplTno4bnhnWDM5K3RS?= =?utf-8?B?b003MnZDc2ZvOVU1alRyTHNKZlZFK1d0OHhoK0ExYi9iY1hhak9uMVlMNDdr?= =?utf-8?B?NGVMb3B0WG9haTNKRUUwbnM4cnlnOEMyaldqUi96TnNxTzVlK2xQa3oyM3Vv?= =?utf-8?B?bjJpS0wwRGVVWkpBYkgvY3YvS0d0T09KYkVsb2FNNVdJcHVEQXRLRHR2R0JD?= =?utf-8?B?WVJLTklUV01nN2Q1SGorMTM0ajdrcmpJdU1GOXVwcGRsNzFneVZEY3ZXRXpk?= =?utf-8?B?K3pIMFlNUXJqWnRjUmVScWJLOUFsMExEMjJHKzJBNytiellmKzRjdHdkLzVz?= =?utf-8?B?WGliRU16Qm9wb3ZuYy8zQis0QzZzQ3E1YnptTitGRnBJZXdOMUM2SjNYT1Ey?= =?utf-8?B?cW56MUMyYnJ0MEtQM0NDT3BVQmhoN21zM1A5eWJuN01qenRJclNKQ2R0bVpF?= =?utf-8?B?UUhaaTVZaGdza1E4NTJYU01SaUdsbm1MYkpRM2ZOKzZZS2hJSWVMc2M4dU5N?= =?utf-8?B?VDB3dVhnaDMwck5SYnB6UlB3blFPR2MxRnlTNmJIbERNRWxpejY2cXdjY1hN?= =?utf-8?B?dkc0VFJZS2UvS2NXVW1ia3lTbnovSHZEUWQva2xMcUdySk1JcDEwYjczM1Az?= =?utf-8?B?bitaUGdoUkFaeEpaalBqQXlMTjRRUUNmb0lEMkhjWmplQ1Z2OE9Tb05qclFX?= =?utf-8?B?NGpEci8wemVqZUw5Unh0SklTTjJ1R0Zaa042VE9UeTF4TjZpTlgwbE9qcHh4?= =?utf-8?B?a1BFcUcvK2pFRnBSMXREbVA3OVQ1dUFCQ2h4T1F5RXZJUG15WTl0ejR0bkZ0?= =?utf-8?B?VUZTM1A2WTVJdDhPWnhBa2swT1QwZk5TZDdOUmpET1dMd0JtWWJwQXNxUkpW?= =?utf-8?B?enZxWHhCTFZMN0ZtVmRVdFlJdG5sVVBZdlF0NGZTa01QTENaWStLQzNlWG1j?= =?utf-8?B?elhZS3ZHcERZRGNrNUJ0TG92eXo3Z0c1Yk1KeW1NZG1IYndEMVZWdW81eUF4?= =?utf-8?B?M1hoQkFOSTNkUis1VlBKaTNud0tIeGF2UENKMDB6RXByTGsxOFRybDk1Tk52?= =?utf-8?B?OWxRQkFSWGpRSjhCendkMWJ6Z1NzN1ZOT3JlSzh2RDdBWVJXdDJBYVFleThm?= =?utf-8?B?aG4xRGdlMHRZbDVkdE5kTEpTNFdIZ2JEa1dpb1MxaEJPbElCN2R5L0k0T2dP?= =?utf-8?B?cllXYmVvL1dRa2xkeXFXNmd4Y3Y4UE0yeXdmYTNwYmMrajNMZHBzY3pnOTQr?= =?utf-8?B?eUJCVXN4RCtocTkwTk9PUW5seDhSTUxpdTBDOWpDdHo1cXNwQ1ZFVXpRa3JZ?= =?utf-8?B?R2RsbGdKVzhRYkZwNXVrRVBrNC84UWdhU3pWTGdZL1NIKytISTRzTjd3eHV3?= =?utf-8?B?WWIzQzFtT0NoSUMxTTZlUlJBd0NPUm5QTUcxYU5ZQStjR0ZpSEJ2bms0RzVm?= =?utf-8?B?cXV3SWNxUTFJZW8wcnlOWHRkRzNwMjM2SzVEWWlXYzVLNDhIY1pkUWxMZllt?= =?utf-8?B?aXFkQWRmTVRZbmNmcHkvc3FlU2NsWVBVV2xQNWk5V0lrSW4vL1RyYlVETUxV?= =?utf-8?Q?nZHdQ8oWHrnib?= X-OriginatorOrg: cs.tcd.ie X-MS-Exchange-CrossTenant-Network-Message-Id: 16ba635f-c85f-4388-ce32-08d9325d0d5f X-MS-Exchange-CrossTenant-AuthSource: DB7PR02MB5113.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jun 2021 13:29:08.8465 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: IWR6jZwUoLoXF3/DZgWKzRMA1B/YVfPqG4zE4LVcTKDRlxHfLEp4gw6IfDK/OGlG X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR02MB6924 Archived-At: Subject: [openpgp] openpgp WG design team plan X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 13:29:18 -0000 --kcDM1G3ezXQLA5NyJjRsXR9qUuk93XMrU Content-Type: multipart/mixed; boundary="wNYWq1w7b9ICkPlnP12uVrnAWovmAyUxR"; protected-headers="v1" From: Stephen Farrell To: "openpgp@ietf.org" Cc: Daniel Kahn Gillmor Message-ID: Subject: openpgp WG design team plan --wNYWq1w7b9ICkPlnP12uVrnAWovmAyUxR Content-Type: multipart/mixed; boundary="------------7255840BE18B9D8B6C2FEEE8" Content-Language: en-US This is a multi-part message in MIME format. --------------7255840BE18B9D8B6C2FEEE8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, As you may have noticed we've not asked for a session for the openpgp WG at IETF-111. The main reason is that we didn't see that being so productive for us at this point as we probably need to get more of the "catch-up" work out of the way before it'd be a good way of using so many people's time. So, in order to try speed things up a bit, we (as chairs) are going to try form a design team. Our idea is that that team will consist of the chairs and editors (Paul and Werner) and a few others, will meet roughly monthly with the goal of reviewing all the changes needed to bring the WG draft up to the same level as the earlier draft-10. We hope that the DT will emit an I-D also roughly monthly, as changes are handled and committed to the repo. For those less familiar with the IETF's design team (DT) concept, a DT is a group selected by chairs who do some work that is then an input to the WG - whether or not the WG have rough consensus on the DT output is up to the WG and not the DT. For this DT, we'll have a closed mailing list with an open archive, and, as stated, roughly monthly calls. So, if you're interested in helping out, *and* can commit to making those calls, *and* to reviewing changes in between calls, then please drop a note to the chairs. We plan to try get this started in the next couple of weeks, with a goal of resolving all the draft-10->WG draft issues ideally by the end of August (ok, that's optimistic, but hey, why not? :-). Thanks, Stephen & Daniel. --------------7255840BE18B9D8B6C2FEEE8 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Description: OpenPGP public key Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------7255840BE18B9D8B6C2FEEE8-- --wNYWq1w7b9ICkPlnP12uVrnAWovmAyUxR-- --kcDM1G3ezXQLA5NyJjRsXR9qUuk93XMrU Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmDMn6MFAwAAAAAACgkQWrL68XsXK+rr vQ/+IkwXFNjlekfopy/RDy0vLFpNvHdwINm0LJN86sMVBXF3HpOb8wV8J0vHsQViK8iL3w1HoDTI dN9XveAF6Bb36pFykS43z2XPnDBs6uUAz7iPO6FNh+Uy0sXMDRtWIok92BS1c5WIIHNRfOhH7mNM 8sbmlcv+O0d1wdIcdmTBdK33FQWkBDgMAfV+CkxFiIemY7TLcS8xV1sprTTb6flLqxm+I5+Ut/Qh MSZti5FegnwrN/eFHKZ1y04JgN4qyPaD1cub6nv/CukvTBH9iRrAmPfilOJhNe55yi3UoI8N4oGI X5BEFthW1Q8Tb1LIA44BxWZJM1MMdUKZySYxH2XBrigBeAJBz/ZGThRjRQ6YGS4JG2xuz69u/uI+ oXIHMaDSreEKdk7Ty7qb5LqWg3E7LGEWzEVnQ90yN6UOIb8+550M8wb0otd3oHZ9/zTlXXSWFzs3 g3jJXYnLlLAPjxKEmkh9py5q+fhOPjFQgjyhIWhPkJDvI74TIGY6cDod22aRNXJAIkMVcQGzcknT XCQHucnvoSfOfwOQ5ZDj9rVUaVVI0X7n4fsEIxmDXZsbpljz3dR6AeMvbZMBwuL91+KTXL20ilvg oYFBiBgdREtJkCbYtbU3YOrZD35YWt/QmP1GJRLMQn1eXTfD7s6+Ho0eUJ1QC5f9wkLj83Zc0OFX qE0= =4GpF -----END PGP SIGNATURE----- --kcDM1G3ezXQLA5NyJjRsXR9qUuk93XMrU-- From nobody Sun Jun 20 18:16:53 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C4C3A1B17 for ; Sun, 20 Jun 2021 18:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001] autolearn=ham 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 jDuWcQnnX0gY for ; Sun, 20 Jun 2021 18:16:48 -0700 (PDT) Received: from mail.direccionemail.com (mail.direccionemail.com [199.195.249.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF453A1B15 for ; Sun, 20 Jun 2021 18:16:48 -0700 (PDT) Message-ID: From: =?ISO-8859-1?Q?=C1ngel?= To: openpgp@ietf.org Date: Mon, 21 Jun 2021 03:16:42 +0200 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [openpgp] Multi-algo pubkey, or how to create future-proof keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 01:16:51 -0000 Hello all I would like to bring up a point I had noticed some time ago, about having multiple public keys combined. A few days ago, we have been talking about v5 keys, potential Post-Quantum algorithms, etc. In OpenPGP, when creating a new key one faces a first-mover disadvantage. Since the openpgp key itself is identified by the primary public key, only one public key algorithm can be used. Then, when a new algorithm appears which is -hopefully- more secure, choosing the new algorithm means that the key cannot be used by people with old clients (in some cases, prehistoric ones). Whereas using an old algorithm with better support leads to no incentive to implement the new algorithm, or to use it. This also means that if a critical vulnerability appears in an existing algorithm (such as a Quantumcalypse), finally forcing the use of the better algorithm, everyone will need to create new keys and the WOT will have to be re-created from scratch. Note that subkeys don't help here, since if the master key is newer/stronger than the subkey, the key won't be accepted by old clients. And if you use a subkey stronger than the main key, an attacker could just add a new subkey under their control. The solution I foresee is to spec a way to have a key with *multiple* public keys. When signing, the signer MUST provide signatures with all of them. When verifying, unsupported algorithms SHOULD be ignored, as long as one of them is known and least verifies correctly, it's considered valid. Note that if a client sees a valid signature with algo A and an invalid signature with algo B, it MUST be rejected. Skipping is only for the cases when the algorithm is unknown / disabled, not for ignoring invalid signatures. I initially considered this would need to be included natively in v5, but it can be implemented as a special pubkey algorithm (e.g. 255) defined as a concatenation of two or more public-key packets (using algorithms other than 255) and whose signature is a concatenation of as many signature packets as present in the key definition. This is just a high-level description, it obviously needs to be formalized, but hopefully it conveys the idea. Regarding scope, it seems suitable to include into the cryptography revision and, although not strictly required, being included with a major version would probably be helpful. Does anyone have any comment about including this? (either about the general idea or using that special "pubkey") Best regards =C1ngel From nobody Mon Jun 21 02:50:20 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E863A2A7D for ; Mon, 21 Jun 2021 02:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 f8H-zcX8ww7Q for ; Mon, 21 Jun 2021 02:50:13 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCAF73A2A74 for ; Mon, 21 Jun 2021 02:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=H6eeF42m07kfOh9yOy7duhvTCx6e2WSA+sVWIgWyYek=; b=CHDGOWHNDmeIelks4l1yCXUgBL DVGHAntoYdp1qeDbnWxYsag+fdL2o5wWe+uI3bXy+h+VYhMDT1qUMllxqIZfPeozTKwAh59zxDCRR BeCnvTw40prx47IXmC3jU+WYQYEr2JRCMJz0baj7DS/6k/1uVWnHtz/AgrsyLTIcWexY=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1lvGZF-0007zO-2e for ; Mon, 21 Jun 2021 11:50:09 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1lvGXO-0006Sj-Ae; Mon, 21 Jun 2021 11:48:14 +0200 From: Werner Koch To: =?utf-8?Q?=C3=81ngel?= Cc: openpgp@ietf.org References: Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: =?utf-8?Q?=C3=81ngel?= , openpgp@ietf.org Date: Mon, 21 Jun 2021 11:48:14 +0200 In-Reply-To: (=?utf-8?Q?=22=C3=81ngel=22's?= message of "Mon, 21 Jun 2021 03:16:42 +0200") Message-ID: <87wnqnpmzl.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=investigation_BECCA_SIG_FIS_Power_outage_Maritime_domain_awarenes_NC"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Multi-algo pubkey, or how to create future-proof keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 09:50:19 -0000 --=investigation_BECCA_SIG_FIS_Power_outage_Maritime_domain_awarenes_NC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, 21 Jun 2021 03:16, =C3=81ngel said: > Regarding scope, it seems suitable to include into the cryptography > revision and, although not strictly required, being included with a > major version would probably be helpful. This is not part of the WG charter and thus this should be deferred for a future revision. It is also possible, as you noted, that this can be done as a new algo. Fortunately 4480bis has a goal to make it easier to come up with new algorithms. n any case, it is always possible to write an I-D for an extension of OpenPGP. We did this for ECC and I think this is the best way for new experimental algorithms. Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=investigation_BECCA_SIG_FIS_Power_outage_Maritime_domain_awarenes_NC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSHd0YfKgdOvEgNNZQZzByeCFsQegUCYNBgXgAKCRAZzByeCFsQ eiuNAP4gtnnhTYFfKv62lFWaCno6iT1w6jVIiq7TQqtx9jFhCAEAmFCYsFh0kP+u d16s8ROzfIJR0P2S+rrJ+0xZ7IS70wk= =G0sA -----END PGP SIGNATURE----- --=investigation_BECCA_SIG_FIS_Power_outage_Maritime_domain_awarenes_NC-- From nobody Mon Jun 21 14:07:11 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8083A19BC for ; Mon, 21 Jun 2021 14:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cs.tcd.ie 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 Nmf2b8UzfkqS for ; Mon, 21 Jun 2021 14:07:04 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2092.outbound.protection.outlook.com [40.107.22.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2503A19BA for ; Mon, 21 Jun 2021 14:07:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XS5Sg7wCjaiH6qdZMqtzUjbK1W/a1pGhOVPPrPIj25xVUvQW4osQe0b5R1I1iyHp4wXs46zRx7s9vvhJ8g24bkyN2aMEKOZ/2gOHLoSZYs/J7nedUz5bQQMyFDaEngcSutzzlkKHMdo9bA68kMQyOAIGl96zidXS07wzmi3oqAZNAy8GEd8cdqOq6WvSB4zeGLbwPwIP1SwvdSgLr6njbjY49eLLI8ge+N0JHeeT5iqJ9AUt9hvS5qsSmoFl6vijYJgduS3nHIpvIG92pZ6y2Qe4U7lYiaeXQu68eAnXK6jj8rgs0JPBLoxPiL1QgKlutnJu4j9kYb8G9dtjvN2Dog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fyoE07yDGiqIHobFQCc1ZDaMDicRDHlc18i9DajRt9s=; b=QpZeAi9FB1HgNp8F4mgs3btqJNqe+eJcaQxramHX6m9BRYI8FJ3esbE2Xwk1u/FtCJapJHJazKajr704/C4bTUNAPfu7qqFo6sBKZu4ASB76RHmuDZHLHiWY1ewNGzBpvuz5QvpAYM8EIs43znGZMwoX2iovlJcBuy4Z1CRH/I3EzcrfeGgJVmNZ85qg+AGckqyA+ay680ipLBhR5wTBkV/0GpjEkMmry4z3ObOk53Txt94eJO+ojHCnTxHV1d7ix6ordFlsi8v8MRLOAp2WjQy9bn0QbH4Plq07t+DO7NUioJltWVVlm99jfxvlwW1d+MHWOBbntlmqAmkohNpZGg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.tcd.ie; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fyoE07yDGiqIHobFQCc1ZDaMDicRDHlc18i9DajRt9s=; b=cxC3uIMQGGwvxkDAl+fLiZN2z8GhMTLZKM3Vb+iV4eEP0NEiAOtPoh9vl0mxjVDL2ctbhCgQ64if1TUgiKLpI41FMe0wcMavsxxHc2mGtk6cEcWNcqv2ssJOX/v8y4khBFMKXfbqoqqZiK9HN11XjXMzWl3FdtKCvTuU3bb78q85VpYS9wZxAjFR5J3jJZODFp+DwfkppeRgsRsMXRen93ft0ocWbuiwfs7XD0bFS39MmH60znIX0FkTBiGvsgfj3wvSLeODhUXrO5yapS8Q2gsIdiayTm/1k7im2mA/GgAAVLQ9uYy8bLMJfBnjQ5ZAmOo7xY5o+Vl3ejHkUEjv7g== Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cs.tcd.ie; Received: from DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) by DB7PR02MB3979.eurprd02.prod.outlook.com (2603:10a6:10:4e::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.21; Mon, 21 Jun 2021 21:06:59 +0000 Received: from DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::9c71:9f6:9136:f849]) by DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::9c71:9f6:9136:f849%6]) with mapi id 15.20.4242.023; Mon, 21 Jun 2021 21:06:59 +0000 To: =?UTF-8?B?w4FuZ2Vs?= , openpgp@ietf.org References: From: Stephen Farrell Message-ID: <5c434bc7-009d-09d6-6864-f62835802273@cs.tcd.ie> Date: Mon, 21 Jun 2021 22:06:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0ELIrc1IcXWpnIG8N4U2votdWDmOyuL2L" X-Originating-IP: [2001:bb6:5e5e:b458:b76f:139f:30e2:a79d] X-ClientProxiedBy: DB3PR08CA0010.eurprd08.prod.outlook.com (2603:10a6:8::23) To DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2001:bb6:5e5e:b458:b76f:139f:30e2:a79d] (2001:bb6:5e5e:b458:b76f:139f:30e2:a79d) by DB3PR08CA0010.eurprd08.prod.outlook.com (2603:10a6:8::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.18 via Frontend Transport; Mon, 21 Jun 2021 21:06:59 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d43da306-18d7-457b-c7b0-08d934f8825a X-MS-TrafficTypeDiagnostic: DB7PR02MB3979: X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True X-Microsoft-Antispam-PRVS: X-TCD-Routed-via-EOP: Routed via EOP X-TCD-ROUTED: Passed-Transport-Routing-Rules X-MS-Oob-TLC-OOBClassifiers: OLM:4125; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: tx3AVT2RfN9TeUBxFIQDnSTYAOVvJ31HC8C65FGhzVlXpXCSD19KcQbe6VQeoYD0ZfP0qveKdCaT8tJaBdgKKMnwJtA2HBgNQsAoI8IakQafSPl9z9W1c5FOH6TZ4KbLCAs9UPM8Sj9tc5Y6BDYAv3JSXPsp7RybIlkTn1W60c0HAtZuvH0dTy/5lSJWPgtnQt3aTC0TI1sOw+MFwm7uRHBxfRvO813v/O3FcmyeD+bmNuyVAZfNtUgO3/UBxAyAsHCnXzqZXIWeFjp7m76cKaqhZmjO8ag020a5LHvoS2MDaOrhDRDrr4/29CCUlfK465FtvFK2CXsaQqf48WeUUGeOnFQP4XEfUwWM6y3wOp7xUieQs5qogANKrtSy3tt4aThAINPU4xANVaIObIDrz2cpqots2JEbfIq2TDalwsu5ajD7ErDAle+DUmKRaScAzFlywF+juNZpWprcSonR5rgs/S7uTCXvgc0ZETcpmscRFF6D4fKR+PicB4cp4z2/M1BSbQkJa0KMmQvUeppJQdlx+Zzalm8qOOCB0oPiicBoYSeTLUZcQu0JjrZnT8p2aRHjJ6lnQ/OKz6d8e7g2swNN07+XuOc/m3rqoK0BDXfrVO3CqRwQvhlLCvvwSxRQ1NTnK8GsnEjD/vuU05pKjzj7PzdvoIDm5Y+5TrONexdA7HzFLs7CKSnI6/+R/NIK X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR02MB5113.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(346002)(366004)(396003)(39850400004)(6486002)(83380400001)(66946007)(186003)(16526019)(8676002)(478600001)(36756003)(38100700002)(66616009)(86362001)(2616005)(33964004)(31686004)(66556008)(44832011)(66476007)(5660300002)(235185007)(31696002)(8936002)(2906002)(21480400003)(53546011)(316002)(786003)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a3A0TTZ0aUY0WGlWTWtKSFYvMWpmTUlxYmpxTjk4N2xvcFYvd0ZGZStFV1FK?= =?utf-8?B?ZmRWRU9wUHU1WnBQTXIvU2FwdjMrOHRpKzBGVVRNS1hUTHNrU1pHTit2Z3hX?= =?utf-8?B?dk5Qa3VTVUZLODZGT0pRUU9GeW45N0R2Y0dDc0FNS1VEODhQWlRGclZBOTZU?= =?utf-8?B?Vnd2RzE2RGZycFp2UmVURytrVlJJblZMbXh4c0t5dkxPcE9XKzBpQUZBV0wz?= =?utf-8?B?TmNDeG5qaERJVkUyS1cwZ0hveWRhbkVLeXRZTmJmSnBDQW45Sjg4b1U1Rk5q?= =?utf-8?B?dzFaMXRhR2J3TFc1YWJHUFhDUjh6a3RLZWNMYXc4M21xS3dzSGw1MDg3N01Z?= =?utf-8?B?RkNBVDAweE5XajdtV0VtdmliVi9IZkhXYjZ6TGVlYnc3UGR5NWVtY1JGdVlw?= =?utf-8?B?Lzl4T2RqSlNYZDJqb3NTT0FCQ284RGhzME8wQW5pSFdtL2JUb3ZlK0IrUkE2?= =?utf-8?B?QTRiTTNKRHJDM0ZoR2lNbDMwR0J6aFo0KzZyWTdmbDFhcER3Vys0a2NhNjF4?= =?utf-8?B?VkdkUWNOM1dNYmM4VHN0RmMyMXFOZW9iVERSQkhnZ2sybXBWcmhNRXUrM0hw?= =?utf-8?B?Y1JUMFFobU1jNlAvZ1B3dDhXV0RMcUZnUGVRcFVzSWZrUmZsOTQ1dHdNWVFI?= =?utf-8?B?VFdkbmc3ZnI0SmR2b3NOYnc4L05ndFJ2dExlYWdaUjdmK24wVENUcFV4N2RB?= =?utf-8?B?dytIWDFENDhwT0dSWnkzTzlTZVVPYXBHQ1hKTGxZbmRHcjNxM3FSK29SM2Fm?= =?utf-8?B?dmUrQlVYTVo5cVYyZkpCYVRTS1g0bExRd01pc3cyMmJwOUxKQkt4MHhQUldS?= =?utf-8?B?dmh5NFBiY3FxQmtjV2lLekhHcUMvM2thb2hSZlZPVSs5YlViMmJLeXIrNHpI?= =?utf-8?B?RDB3UnhueFJUazFRbm12SnJsYjBXL3J2Y2ovcDI4MGhLaUZSMUJRZVpndy9R?= =?utf-8?B?bkZDK2QvMGhYK0d3R3I5QXN4ZkxaYkUveDN4V3FnT3JrbTdtU05QdXRXNjlo?= =?utf-8?B?VldranYxTFhubUx4RHBPYmR1V0tOYXE4UTNNVVR4S3dEVzQ1cVhESDI0SEN1?= =?utf-8?B?N1BxTVlhNGdIS3hicTF3SjM5SmFhcVMreFdQbmcyZTRFZUlFSGFNUVBKZmhy?= =?utf-8?B?UU1mbHd0cUxwbGZwU0F3YWhaM2VzeFR1QUx0amRYVERxVE90TTJ6MzJPYWpy?= =?utf-8?B?Y3JTSC9maUQxVUZZUFFRRUxUZjBJd1NtYWY2b2RqZUJ5NkhQMlBIVTRid0ww?= =?utf-8?B?VFBGeVpiM2dXQnFRbFFWU3hoS1luNXJYN01sd0tmRUdmMTBmMGlJMkZkN2hE?= =?utf-8?B?NUlQMkdZSGUyTm5paGMvNHVyMmVaMFQ1REFobVF3NTRkZWV2VUtYQWtNNXo5?= =?utf-8?B?SjZDSkdLU2FQc1lLZUd4bElSUjhEQWNYMjZ0RytmSnNVYTJmd25ESEFHK1Mz?= =?utf-8?B?MExXdWw4azRjSXEwZGQrU2dENkF5Smwyc0hhZnRIcGU3Z2FhUWFqKzQzSzIv?= =?utf-8?B?dVIweGNRM3Q1ZXl1cE1aYTJpM1RRZDRpS1Y2N1kwR0UzdXpoY3VqdzMzaUQy?= =?utf-8?B?TUU0QXVxR2JwTisyQURJOVRxQXVYM2NuRVpVK3RuT0N3ejVtSXNzT09uZ3B3?= =?utf-8?B?M3BvVG5JM0lNd3luVGlHcTBHMi9QcnFpVTZicUEyWlFmeDJQS3dUbXBaY0Qv?= =?utf-8?B?ZjJ3YkhCZ0dSK0l6QTdYbzd5bnA3bGFIRVQ5OTFaVzhxUXd1ZnNhVFVMa1BC?= =?utf-8?B?Umx1WkVHNW4xODBnNk1qS0trU1h2NUVjYUNqOWdmOGtJNk9NWTJha2NtUFJu?= =?utf-8?B?TVFDeGxWZFdSZW9hdDJNZHBPNXBDdmZXazVTUlNzenNZdHpzY2tUZkJzYW1k?= =?utf-8?Q?kr+9JBmWvyWyr?= X-OriginatorOrg: cs.tcd.ie X-MS-Exchange-CrossTenant-Network-Message-Id: d43da306-18d7-457b-c7b0-08d934f8825a X-MS-Exchange-CrossTenant-AuthSource: DB7PR02MB5113.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2021 21:06:59.4886 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: iQvSdZdSLFqhI6mWl8M2l9L1pv21PUOSj8Mu2pcCaXh4BIDs7yjnWZlJk8qCPeft X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR02MB3979 Archived-At: Subject: Re: [openpgp] Multi-algo pubkey, or how to create future-proof keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 21:07:09 -0000 --0ELIrc1IcXWpnIG8N4U2votdWDmOyuL2L Content-Type: multipart/mixed; boundary="odX2I5g5Ak61yP8L7XKNq7kMzwg8gmhCu"; protected-headers="v1" From: Stephen Farrell To: =?UTF-8?B?w4FuZ2Vs?= , openpgp@ietf.org Message-ID: <5c434bc7-009d-09d6-6864-f62835802273@cs.tcd.ie> Subject: Re: [openpgp] Multi-algo pubkey, or how to create future-proof keys References: In-Reply-To: --odX2I5g5Ak61yP8L7XKNq7kMzwg8gmhCu Content-Type: multipart/mixed; boundary="------------5F2B6A323CEBED096028A218" Content-Language: en-US This is a multi-part message in MIME format. --------------5F2B6A323CEBED096028A218 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, (This is just my personal reaction - as chair, if there were a load of people wanting this now, I'd re-evaluate...) On 21/06/2021 02:16, =C3=81ngel wrote: > I would like to bring up a point I had noticed some time ago, about > having multiple public keys combined. A few days ago, we have been > talking about v5 keys, potential Post-Quantum algorithms, etc. I think I agree with Werner that this is better one for later. My particular reasons are that moving from 1 to many keys isn't so much a crypto change as an architectural one and that as you point out, such a change if/when it comes, is likely to be intertwined with PQC (assuming the model of mixing "classic" and PQ algs seeming to find favour with e.g. TLS is also sensible for pgp). Lastly, (and this time looking at, but not quite wearing, a chair hat:-), I'd prefer see us progress the "easier" work first and then attempt more ambitious things. Cheers, S. --------------5F2B6A323CEBED096028A218 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Description: OpenPGP public key Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------5F2B6A323CEBED096028A218-- --odX2I5g5Ak61yP8L7XKNq7kMzwg8gmhCu-- --0ELIrc1IcXWpnIG8N4U2votdWDmOyuL2L Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmDQ/3EFAwAAAAAACgkQWrL68XsXK+qX SQ/8DcYwvgVXhIeCbXP0wvPL2TYMknwoQAZD23MnHDMKCVhpSnMW4MaWhZnqTQp9uFvaboXkN5vZ 7kGiKbdshwpJqaLvNT8KzOh3ZoscN950e40u+QLJ9AH+5tK9PBtJOx54HPXVE7LBLnAtirvoHoqe XbnyUyqXPWr9xR98KU6qvhGTOImbpkcrZDTpMcXOg5i1RG1IGhAxt5HQggRzOYXZzFnb+EddRbrJ NSBmKPc0bPzSYxzjrNMgnC6tjSCzhmYrzoTKjkLFRHY89MBL7v7WXudH035QUlBHt+Lzlv5vrmqd ub2OtqKAAGcebMKnv1ySVWLBVM2wsfuxdIuC6THkAytMxGR8fQ/5d+t618rkLz6FHAarBAwEK1g6 2IV2NXtjJCyF4J7VP7sFFHb5H7NIAakeXER4fKgrS7/eDt6H5/UCrCBQWJBp4/N4DVgw5+/X+Y37 Lc32xROnyhdEl5q/R/fb9xTwj+YcsPY2wrqSHl8WlP2Bf+FM6gqvVskm/rkkniav9w7BittI8HRF EnG5E3M8mx6CEweQGiK3Md6e0qW03FCPgGo5G6cN2Q3U9kKA2XroTyyqww81LOTqxCnNWhTnOfGM 9UEltmyB7Lkexkpbkp0hs9qdcHN+e1CqDcaN6BiFj2qED6D9HPVr0TxBbPV2kECJuH6ytqPZIKM7 mRI= =NmcO -----END PGP SIGNATURE----- --0ELIrc1IcXWpnIG8N4U2votdWDmOyuL2L-- From nobody Thu Jun 24 06:52:18 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213573A1DB1 for ; Thu, 24 Jun 2021 06:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kuix.de 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 4QKj7GlVMzCR for ; Thu, 24 Jun 2021 06:52:12 -0700 (PDT) Received: from cloud.kuix.de (cloud.kuix.de [93.90.207.85]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30A7A3A1DB0 for ; Thu, 24 Jun 2021 06:52:12 -0700 (PDT) Received: from [10.137.0.17] (p5dcf40f9.dip0.t-ipconnect.de [93.207.64.249]) by cloud.kuix.de (Postfix) with ESMTPSA id 21E741905ED for ; Thu, 24 Jun 2021 13:52:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kuix.de; s=2018; t=1624542729; bh=YB+w3HXAHVGnnePNaRuUwWDwo0Auy7NPYg75yR/4RmE=; h=To:From:Subject:Date:From; b=XuFc4TehpTMOu00GyHSXFL8TBEg33Z0CAhf+PazyMekNOCgew9WsxTKA+2htMH5DL wwOBiVK/ZIpaAw7aWiejpPiT6/oK/pTJypaG0qmV8ywd4hPrXw1nheB+IgzD8KI/5j VGf55U6Ch9405mtFiK7CeY8xeI294Z4v7IoPzwOB6uzC/f6amslzm09KWOINp5Zq6H 5HGA+15ZqSBca4eJmX08C6zSIBVNfXclXzsgk/h7CR9ewKQ8hhLd+he+bOWjwdZs5X uDB5s4CFhWFOg7j0vbAWMbU4iAf+lzaCJ2pkAQxNDlZSz9L5UDwEams2RSrwnKRG1x VHlVLraHaXSJA== To: openpgp@ietf.org From: Kai Engert Message-ID: Date: Thu, 24 Jun 2021 15:52:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.11.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [openpgp] German BSI, PQC for OpenPGP in Thunderbird, X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 13:52:17 -0000 Hello, I'd like to make you aware of a project call by the German BSI (a federal agency for IT security), which was brought to my attention. I've posted some information on it on the Thunderbird planning mailing list, see the following thread, which has multiple messages from me: https://thunderbird.topicbox.com/groups/planning/T5abbf135db2f3c1c/the-german-bsi-intends-to-sponsor-pqc-improvements-for-openpgp-in-thunderbird In my understanding they intend to pay a contractor for a wide set of tasks to bring PQC to Thunderbird, including the work to standardize the use of PQC with OpenPGP, including implementations for RNP, Botan, GnuPG and libgcrypt. It seems the BSI has already made a suggestion that they want to require the use of CRYSTALS-Kyber and -Dilithium. Is that a reasonable choice? Does it make sense to define a limitation to these methods at this point of time? Thanks Kai From nobody Thu Jun 24 07:40:09 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C163E3A1F19 for ; Thu, 24 Jun 2021 07:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 ePWcbwIFmT1l for ; Thu, 24 Jun 2021 07:40:03 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0A03A1F1A for ; Thu, 24 Jun 2021 07:40:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 5111CE2040; Thu, 24 Jun 2021 10:40:01 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 27133-01; Thu, 24 Jun 2021 10:39:59 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id D36B0E2045; Thu, 24 Jun 2021 10:39:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1624545599; bh=WrFaYnj/VOWDn0dzQT3pYhf9uGcjFFjoXyUoFI5xWwU=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=Ma9MF+ANiIO/XNYqK6VjQkjqqN/RcTQ0/gPQrR8qEVEyWwGTW+2HN1NFKRBjbHwUY AZjEYOl4LE9BaK6PW/Jx/4SPNhY3BZySWDmmbfBpQyV1w1iI2Opx1vVUfQTwJKy0kb LUeDwffeVLXsVOWv/kDlGdo5r/PyEv7y9oTH1sTo= Received: from 73.126.63.116 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 24 Jun 2021 10:39:59 -0400 Message-ID: <6dea5f0d481349c211224e256e23dd1f.squirrel@mail2.ihtfp.org> In-Reply-To: References: Date: Thu, 24 Jun 2021 10:39:59 -0400 From: "Derek Atkins" To: "Kai Engert" Cc: openpgp@ietf.org User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] German BSI, PQC for OpenPGP in Thunderbird, X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 14:40:08 -0000 Hi Kai, My only concern at this point in time would be the question of what PQC methods to include? Right now there are still way too many choices, and there is an expectation that NIST will reduce those choices over the next 2ish years. So does it pay to do the work now, or perhaps wait a bit for Round 3 to finish, before we potentially add methods? -derek On Thu, June 24, 2021 9:52 am, Kai Engert wrote: > Hello, > > I'd like to make you aware of a project call by the German BSI (a > federal agency for IT security), which was brought to my attention. > > I've posted some information on it on the Thunderbird planning mailing > list, see the following thread, which has multiple messages from me: > > https://thunderbird.topicbox.com/groups/planning/T5abbf135db2f3c1c/the-german-bsi-intends-to-sponsor-pqc-improvements-for-openpgp-in-thunderbird > > In my understanding they intend to pay a contractor for a wide set of > tasks to bring PQC to Thunderbird, including the work to standardize the > use of PQC with OpenPGP, including implementations for RNP, Botan, GnuPG > and libgcrypt. > > It seems the BSI has already made a suggestion that they want to require > the use of CRYSTALS-Kyber and -Dilithium. > > Is that a reasonable choice? > > Does it make sense to define a limitation to these methods at this point > of time? > > Thanks > Kai > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Jun 24 08:40:43 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B0F3A2123 for ; Thu, 24 Jun 2021 08:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=uz82KJpu; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=OL/GDApV 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 O-LmXs700mJ8 for ; Thu, 24 Jun 2021 08:40:37 -0700 (PDT) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D00F3A2122 for ; Thu, 24 Jun 2021 08:40:37 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1624549235; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=k1CfFBotulJK+L9btj6+CsbQ2XhZEPnOz0ZXTSQNIO8=; b=uz82KJpuL7vEJzUVyr9ZhxyTi3qV0pdxowjjOiFKfAg7ch3twJumZCz4cOX21GDSCtU3G kRQoJ1Sh1/J3JExBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1624549235; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=k1CfFBotulJK+L9btj6+CsbQ2XhZEPnOz0ZXTSQNIO8=; b=OL/GDApVyy3SFKIrCURJO4/XY9ZrKEHHy1AX7RePXkH7rUsbbcIHa9qD/9qyO7DOTN9PX 4tYN7sqTrpYq9NAObPEBgou1l3fqAFp+DI73PvVSpkT+YhOiEwMK0HWz4B9l0IZCkLnUtkm Agzf29AKzy2knG27ioH4f0AD9sGmnDYNEvaCHkOiyTb3gdHZjbz7hwvuOj1EUwH33ZLHhhV PaaRGQshJOgHVKGAZTzyhCo+ILHEivZD57hImvRR9S/nfez3g4jYrNfJwn+v3jdr+OAeJg7 F0M8Jho4HhnNicyiGv8/8f5+3KZjqteIvJlsjC/Hbn2WwCmljPIfgcVuYQtw== Received: from fifthhorseman.net (c-73-106-144-119.hsd1.ga.comcast.net [73.106.144.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id E0784F9A5 for ; Thu, 24 Jun 2021 11:40:35 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id E654120362; Thu, 24 Jun 2021 11:17:00 -0400 (EDT) From: Daniel Kahn Gillmor To: openpgp@ietf.org In-Reply-To: References: Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Thu, 24 Jun 2021 11:16:59 -0400 Message-ID: <871r8rwavo.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 15:40:42 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu 2021-06-10 05:40:34 +0000, Peter Gutmann wrote: > Daniel Kahn Gillmor writes: > >>Key ID or fingerprint comparison has been recommended in the past by the >>OpenPGP community as a reasonable way that one communications peer can >>confirm that they have the "right key". > > Ah, good point, so it's a human-factors thing rather than just (say) mapp= ing=20 > a signature to the key that signed it, where even if you can create a=20 > collision to point to a different key the signature check will still fail. > >>which i'll call the "comparison-verification" practice: > > Is it worth mentioning this in the text? The current text just says "thi= s=20 > thing is the fingerprint" with an implicit use elsewhere in the doc of > "the thing used to identify which key is being used", without mentioning = its=20 > second, non-protocol use, to verify someone's key. I would welcome a proposal for brief text that describes this use for the revision of RFC 4880, though i think a full description of fingerprint-based verification (and other alternatives for key confirmation) is probably beyond the scope for the crypto refresh document. It gets complicated, and the best practices are still pretty unclear. > (Is this still done? When was the last time someone here attended a key= =20 > signing party?). Yes, it is "still" done, though i'm not sure it's ever been done to the extent that the OpenPGP community has traditionally imagined it would be. "key signing party" is not the only context, either. i've got dozens of business cards or small slips of paper which contain OpenPGP fingerprints (either as text or as QR codes) that people have given me at free software conferences, and i've given them out myself. do people *actually* verify them effectively? that's another story=E2=80=A6 --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYNSh7AAKCRA+nXFzcd5W XDQqAQCHyxMWFz6aoUQxA9I5SkXCQ/b/NEwDyVrOMb9u8OHsyAEA5/rflzXg3Fuy oX/SGWcYCDdl9ZKplTjRe2UZ36dNDQg= =yx8w -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 24 08:40:47 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3783A2122 for ; Thu, 24 Jun 2021 08:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=IXirzcCU; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=Ka+p47uA 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 KROGXUfBEgqT for ; Thu, 24 Jun 2021 08:40:37 -0700 (PDT) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCAC3A211F for ; Thu, 24 Jun 2021 08:40:37 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1624549236; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=VVYpZZ/oCP6TJShyz/ij78niPMxMj7IOvGn9o+kmBpk=; b=IXirzcCU5u0eWELo/yGOqk1Nexif0dUbCS9n0QmVcXt0NqyTg2LuUBY4/kcj0SbX7PN3a qkH2vpP3SX6EZbVBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1624549236; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=VVYpZZ/oCP6TJShyz/ij78niPMxMj7IOvGn9o+kmBpk=; b=Ka+p47uA1/eFQtV+nY8zIVG5WJNglVCpCSNdKR3LWPq6woPx1ztwthnrdnutSfSED21tD eh4Q5zqIiqBLUUHiYASgx5xjRKrV/GwLDCQBESbp9JcGZI/6zaAhZsLNQz6PnTVdV0IJZa+ Z/aweMsdIoW7WPz2BNWzrXB6gnB/2DQZmpPVxhOVF5McsOG4XI05zCEoH3ZqAa36FqSOOCt c063lSUTEDPiLVdyilJflBq4rjegnH2xJGs3vvIKSBj6rLP1/uvwnqzUeQ/KMx6+Ek363fr u9WARS+xNFbBq/s06Ys9BLtHQ23zj0aes5C0asIpdTiaoUlG4SB8uL3CG33g== Received: from fifthhorseman.net (c-73-106-144-119.hsd1.ga.comcast.net [73.106.144.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 1CB68F9A6; Thu, 24 Jun 2021 11:40:36 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id E46E220554; Thu, 24 Jun 2021 11:40:22 -0400 (EDT) From: Daniel Kahn Gillmor To: Kai Engert , openpgp@ietf.org In-Reply-To: References: Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Thu, 24 Jun 2021 11:40:21 -0400 Message-ID: <87y2azuv8a.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] German BSI, PQC for OpenPGP in Thunderbird, X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 15:40:43 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thanks for the heads up about this, Kai! On Thu 2021-06-24 15:52:06 +0200, Kai Engert wrote: > I've posted some information on it on the Thunderbird planning mailing=20 > list, see the following thread, which has multiple messages from me: > > https://thunderbird.topicbox.com/groups/planning/T5abbf135db2f3c1c/the-ge= rman-bsi-intends-to-sponsor-pqc-improvements-for-openpgp-in-thunderbird > > In my understanding they intend to pay a contractor for a wide set of=20 > tasks to bring PQC to Thunderbird, including the work to standardize the= =20 > use of PQC with OpenPGP, including implementations for RNP, Botan, GnuPG= =20 > and libgcrypt. I appreciate your providing an English summary of the call for contractors. I'm glad that the BSI is interested in this topic -- i am too, though i share Derek's concerns about whether standardization is premature given the state of PQ cryptanalysis. I'm a little surprised to see the BSI simultaneously proposing standardization of PQ schemes in OpenPGP *and* advocating for implementation of a specific scheme. I'd expect the standardization to involve selecting which PQ scheme(s) seem reasonable for the context, rather than pre-determining the scheme for use. If we can get the crypto refresh done relatively soon, it would be a great way to demonstrate that we are ready as a community to figure out how to get PQ mechanisms mixed into OpenPGP. And, as the thread from earlier this week discussed, one of the ways that we're likely to see proposals for PQC to work would be to have multi-key combinations -- so that we don't introduce a relatively new algorithm that makes things weaker than the established traditional asymmetric crypto; this requires some nuance and planning that are not part of the simple "crypto refresh" mandate we have right now. I'd welcome the BSI to send their own members (and/or delegates) to the WG to talk about their goals and plans, but i'd hope it wouldn't interfere with the current chartered work. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYNSnZgAKCRA+nXFzcd5W XK+bAQCfp/wRWcx7cNk1O7gaUFeN4CgD7bE/gZFR1hcZZvV32QD/eiEx/yruTZnX oChKo7UtUMvPUkEEut8Kwx0viK87gA8= =VBgq -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 24 09:05:05 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3463D3A21EE for ; Thu, 24 Jun 2021 09:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.338, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kuix.de 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 nOljlT2yjTqt for ; Thu, 24 Jun 2021 09:04:59 -0700 (PDT) Received: from cloud.kuix.de (cloud.kuix.de [93.90.207.85]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486D43A21ED for ; Thu, 24 Jun 2021 09:04:59 -0700 (PDT) Received: from [10.137.0.17] (p5dcf40f9.dip0.t-ipconnect.de [93.207.64.249]) by cloud.kuix.de (Postfix) with ESMTPSA id 91B12190608; Thu, 24 Jun 2021 16:04:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kuix.de; s=2018; t=1624550694; bh=q6ajQ2itGoz9ZLBHoUtYuOqx6Aj6+He8xi40409hdDE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=iKMGqor8vDD+qPcWULtImeV33x9/Gc/O4xDNtizMDSxSkJqa+IUB9ao5h38quDu/K kaenKNczzubovZfs4dLfu6nBn16SbxG4ajTlkwxbrfPyPJR2JB2HphwIhfbFiCf191 ZTZBGOwx2ubnZw19uUzb8HLJHHxRPEwBKexlXLFInRQvJFsuAq9wciS2HkM4hzGbH5 FkTo0FQ6mup+ppBa3b6eeU9VqboQVds+CRvg7EA1qHzErXvx8ptcPt1AQzNJfB/gX4 8YJOHG2RqAnZpalBZ0GJfZOKDzWB1kRvHF+OIwOoYxnMRIH4N9OejX1f0iQJEtzcN5 G+VH7NGxhnoaQ== To: Daniel Kahn Gillmor , openpgp@ietf.org References: <87y2azuv8a.fsf@fifthhorseman.net> From: Kai Engert Message-ID: <87144d23-6a91-4fe2-338d-eb910d6ef8bc@kuix.de> Date: Thu, 24 Jun 2021 18:04:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.11.1 MIME-Version: 1.0 In-Reply-To: <87y2azuv8a.fsf@fifthhorseman.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] German BSI, PQC for OpenPGP in Thunderbird, X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 16:05:04 -0000 On 24.06.21 17:40, Daniel Kahn Gillmor wrote: > ... I'm a little surprised > to see the BSI simultaneously proposing standardization of PQ schemes in > OpenPGP *and* advocating for implementation of a specific scheme. I'd > expect the standardization to involve selecting which PQ scheme(s) seem > reasonable for the context, rather than pre-determining the scheme for > use. ... The call mentions that the NIST standardization isn't done, so apparently they intend to follow the NIST recommendations. They also say, the project's cryptographic design should consider crypto-agility and hybrid solutions. They describe a hybrid solution as a conbination of a PQ method with a classic asymmetric method. Maybe this means they're asking for a solution that implements the specific CRYSTALS-* method, but in addition be prepared for alternative algorithms as well? I found that in section 1.3 of document 02 (Vergabeunterlagen/02 - P480 - Leistungsbeschreibung - Offenes Verfahren v1.0.pdf) from https://www.evergabe-online.de/tenderdocuments.html?1&id=397181 Maybe it would be necessary for applications to ask for clarification. (As noted in the other posts to the Thunderbird planning list, all questions need to be asked in German via the BSI project site. And in order to ask questions, it seems necessary to register as an interested party for the project. Kai From nobody Thu Jun 24 09:31:16 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E963A22F9 for ; Thu, 24 Jun 2021 09:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 YM4wNdf9ryzl for ; Thu, 24 Jun 2021 09:31:09 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F38E3A22F7 for ; Thu, 24 Jun 2021 09:31:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B454038BAF; Thu, 24 Jun 2021 12:32:51 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kATQX1jOO_uM; Thu, 24 Jun 2021 12:32:49 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1E31B38A7D; Thu, 24 Jun 2021 12:32:49 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 083011C6; Thu, 24 Jun 2021 12:31:05 -0400 (EDT) From: Michael Richardson To: "Derek Atkins" cc: "Kai Engert" , openpgp@ietf.org In-Reply-To: <6dea5f0d481349c211224e256e23dd1f.squirrel@mail2.ihtfp.org> References: <6dea5f0d481349c211224e256e23dd1f.squirrel@mail2.ihtfp.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [openpgp] German BSI, PQC for OpenPGP in Thunderbird, X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 16:31:14 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Derek Atkins wrote: > My only concern at this point in time would be the question of what P= QC > methods to include? Right now there are still way too many choices, > and there is an expectation that NIST will reduce those choices over > the next 2ish years. So does it pay to do the work now, or perhaps > wait a bit for Round 3 to finish, before we potentially add methods? Reading Kai's email, my impression was that the point of the German effort = is to figure out (sooner) what changes might be needed to Thunderbird, and perhaps, provide NIST with implementation feedback. So, that's why they want to do the work now. > On Thu, June 24, 2021 9:52 am, Kai Engert wrote: >> Hello, >> >> I'd like to make you aware of a project call by the German BSI (a >> federal agency for IT security), which was brought to my attention. >> >> I've posted some information on it on the Thunderbird planning maili= ng >> list, see the following thread, which has multiple messages from me: >> >> https://thunderbird.topicbox.com/groups/planning/T5abbf135db2f3c1c/t= he-german-bsi-intends-to-sponsor-pqc-improvements-for-openpgp-in-thunderbird >> >> In my understanding they intend to pay a contractor for a wide set of >> tasks to bring PQC to Thunderbird, including the work to standardize >> the use of PQC with OpenPGP, including implementations for RNP, Bota= n, >> GnuPG and libgcrypt. >> >> It seems the BSI has already made a suggestion that they want to >> require the use of CRYSTALS-Kyber and -Dilithium. >> >> Is that a reasonable choice? >> >> Does it make sense to define a limitation to these methods at this >> point of time? >> >> Thanks Kai >> >> _______________________________________________ openpgp mailing list >> openpgp@ietf.org https://www.ietf.org/mailman/listinfo/openpgp >> > -- > Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Comput= er > and Internet Security Consultant > _______________________________________________ openpgp mailing list > openpgp@ietf.org https://www.ietf.org/mailman/listinfo/openpgp =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDUs0gACgkQgItw+93Q 3WVlAwf9GsddPzkC4551CyfBM+Ix0m1oG5v3d5m6g5pR+DibuAObsHqYwTmB1nHV 43axi8v0Z/z8DqtwGZEmgMRZ3gZ5FkjSZceT5atXZ5T5X3+2v7YbxrX3DAm+hHyQ dysN91HlcZgvyGKks6r9JkE8pk2NgB6BAm+vSIGRWuZwucRxrBgEXR9iclep37aL 7CU6gyY5GWXu6rHO6A4WG0Qyg8eDBN+Blrn9Okv6dL6togu2amp9ieRj+20WTiI0 IBV4RCHJKKGeuDvGQiP3e6L2qD/m2+DKYNr2V+j6wTaYYKWljLNV8UUPpiNst1+3 hXv0UmUIvAiUx70fM6cGXexop6R8AA== =vFbf -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 25 00:07:58 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF263A3E43 for ; Fri, 25 Jun 2021 00:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UEQPC4nNFnSn for ; Fri, 25 Jun 2021 00:07:49 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268B43A3E3E for ; Fri, 25 Jun 2021 00:07:48 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id n23so5572017wms.2 for ; Fri, 25 Jun 2021 00:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ud3Uxnqrqm5dz4+Kh7auidlUeS93XvRpozJpxqAK5PQ=; b=ceoOjqP7+RNpfoGr2iL6+4lcV1/vT1vBWdVdtG4PuFlJcWzZVhgqbMYgS+1ZDhF9ep KYp6xt4zJd5Pu+X09SYjEY7ylAa1OeWkAwMquFG46Af+BbLCUj7WUvZoQ2TJjs3zKfly LMYToPBsuJ9KrMUbdpiY7R5j33F/m+3SaYRbwP4IXL5VHn2Tz3Y/ruyBNEja1YbbudgU Xb8TooBuKtoAvK3Jigbqu8SeUPBNmZtptrSthQGKK6rmX/DVoOAOoQJ6eRaCQxojS+5N 1eZpJ/6Rh91gfhqy/HGPkH/9q3TL0W0JqtQ55Q+De5sFFVAfJhtLjtvZ+5lf8VONK+C9 9L/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ud3Uxnqrqm5dz4+Kh7auidlUeS93XvRpozJpxqAK5PQ=; b=idZWJvGQrrgZY+ljepVc3KgVHyXpGI6W1P8Li6+JQ+wE9o64HR7/ybTZEFEfUU0Uwo z/aEbSMk6Ea3xYzEZ5gs8mCafPr9QMVsLFaVugOEVn4mY74EMO5UyJkfUDUVEQ2YtfT5 API4DEPatl2/dbED0Gh7Ch4LoKU7kYtQdZ+BGYdyLKKDOj8gXU+4XEZw4iV2ThKI4//j oHTt1pbmaxb6zPfcGOjJ0AiVaoTSCTYyYASxTpoT4jp51A+uIf3f6JO2CLSh4+Wmic/0 HTmrw1L0MvVqdqsn6PvIUyiWMBPQGhW+av1t93pFvlZLQbQXJMwjoonviqcitFlynq8w 5Qjw== X-Gm-Message-State: AOAM531vk6kRAqDmBTHzbZAmCG+YtCaZ2mZzsv0GM5NKP05dUvBHjs1s H7wxp3JOX8g0lYpiR/Ex+KoefrnS4RWMtylstN5VYM4YGFk= X-Google-Smtp-Source: ABdhPJylASdvR8RZxI5nxRvCArzr0jTaWej4JkcBFV2dXFRIadrzmL2EbljbFu0WqUHGy5OeSDv/xPe3dLTxCKn1LM8= X-Received: by 2002:a05:600c:4417:: with SMTP id u23mr8830538wmn.26.1624604866042; Fri, 25 Jun 2021 00:07:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alessandro Barenghi Date: Fri, 25 Jun 2021 09:07:35 +0200 Message-ID: To: openpgp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [openpgp] German BSI, PQC for OpenPGP in Thunderbird, X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 07:07:55 -0000 Hello, On Thu, 24 Jun 2021 at 15:52, Kai Engert wrote: > > Hello, > > I'd like to make you aware of a project call by the German BSI (a > federal agency for IT security), which was brought to my attention. > > I've posted some information on it on the Thunderbird planning mailing > list, see the following thread, which has multiple messages from me: > > https://thunderbird.topicbox.com/groups/planning/T5abbf135db2f3c1c/the-german-bsi-intends-to-sponsor-pqc-improvements-for-openpgp-in-thunderbird > > In my understanding they intend to pay a contractor for a wide set of > tasks to bring PQC to Thunderbird, including the work to standardize the > use of PQC with OpenPGP, including implementations for RNP, Botan, GnuPG > and libgcrypt. > > It seems the BSI has already made a suggestion that they want to require > the use of CRYSTALS-Kyber and -Dilithium. > > Is that a reasonable choice? (Disclaimer: I have been involved in the NIST contest with a submission which made it to the 2nd round. I am not part of NIST personnel, opinions following are mine only.) Kyber and Dilithium are two of the finalist algorithms in the current NIST PQ standardization effort and, as things stand now, thus potential candidates at the end of this year. >From the latest update on the contest ([*] , slides 10 and 11) they are both likely to be chosen as standards. > Does it make sense to define a limitation to these methods at this point > of time? > NIST is planning to announce the choice of the actual winners at the end of 2021/early 2022 at the latest. While writing down actual standards will take a bit more, the cut-down on the algorithms will be significant. We expect a single lattice-based KEM and Classic McEliece for diversity to be selected for KEMs, and a single lattice based signature to make it in the standard which will be announced at the end of the year. NIST also has plans for a fourth stage of the competition, where they will accept proposals for non-lattice based signatures and analyze further the current "alternate" candidates. If the idea is to understand what is the impact of the choices made by NIST when implementing, it may be a reasonable time to keep thinking about all the candidates in the NIST PQ standardization process. An interesting bird's eye view on the sizes of ciphertexts/keypairs and speed of the current third round candidates is available here[**] (from slide 100 onwards). Hope this helps, Alessandro [*] https://csrc.nist.gov/CSRC/media/Presentations/status-update-on-the-3rd-round/images-media/session-1-moody-nist-round-3-update.pdf [**] https://csrc.nist.gov/CSRC/media/Projects/post-quantum-cryptography/documents/round-3/seminars/oct-2020-gaj-kris-presentation.pdf From stuart.schechter@gmail.com Fri Jun 25 19:57:51 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309C63A1A87 for ; Fri, 25 Jun 2021 19:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RLexdDDdgske for ; Fri, 25 Jun 2021 19:57:46 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2D13A1A8C for ; Fri, 25 Jun 2021 19:57:46 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id i24so16104080edx.4 for ; Fri, 25 Jun 2021 19:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TpxZu4vihWB4TC/3MXpXuvWAW9uBOmx+uSllM0T/9eU=; b=MleZIufD0FcJZLvxc2Lf9G+D84H1fVJKhQe1giQVrNQOhQ+dFay7jus1cCY/3xtH1s 2zA38+F2XfeOUE/brL0Tw6qGFaMS+W9zhwEZ3tjgyGEmA8OjjuDS25+9MuRNYiuc7fW/ PJ6E2l9VrISZKAAHpsr55mopKGn9k2bZlU1WCycrj2VOr+r2sJyp73umr3/4fk9jpLnY YnCHASRfg25D9vpt1ioPqhJP++/KxDba3HPZj5BSi4ecgnUuDd1NYdtREwEktNsmOLF3 oCptvVyXYoqnPS9Xw9tvpLV66OcAaatwT3Z+oL4v8D78eEza8J0AjSlfxhoLCshmHhzR Wwmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TpxZu4vihWB4TC/3MXpXuvWAW9uBOmx+uSllM0T/9eU=; b=AbWRINcuq+VqezmSERioZlo04poEupMweEtBZf1mmDpPqqrK9ZfUydee7+v1RQBaU+ mRu3L8Vmg0cIqvShHtmjXinUT7CpZYDkD04QfOrqJ6xgChxWbyYGiy8C8TiUje9fWeOI iXAW395QpzVM0b2vw3WSCGFiItABju9443iUByZbr9RSkBTQ3H6PFAZYLJeKUmYzP8D9 dtdLEz0rnKc+vyJu+V6rjanwXYnBTzy4JUig4+KqpYvW7YqDBoOZIaNGww6/MsIsUGUy f2n2QHsAvoPV8tdyFIzXSzrTirFYBGOeGLrVBs6S5gGxTvztDXd1vstXvktTeFc9xo31 2riw== X-Gm-Message-State: AOAM531+1l/xnrDyxn0wBVFawf2jHYPeKArcLvXyJRsOAA0B1VFLmv/t LWliZknY3fB7V1WxOMEc6ARJX5+zEfITGjLDt7QDzHSTuZHNlg== X-Google-Smtp-Source: ABdhPJzMFrZGjcUBu/1QC6PjX03/sFoInmeGTYj6Q5D/Hj+Q9GQE2G9iWSp1LLKPQqMrnJFtGRoxeHOOb1k09oiX7zM= X-Received: by 2002:a05:6402:31f8:: with SMTP id dy24mr5357186edb.287.1624676263956; Fri, 25 Jun 2021 19:57:43 -0700 (PDT) MIME-Version: 1.0 From: Stuart Schechter Date: Sat, 26 Jun 2021 11:57:32 +0900 Message-ID: To: openpgp@ietf.org Content-Type: multipart/alternative; boundary="0000000000009694d105c5a26bc2" Archived-At: X-Mailman-Approved-At: Sat, 26 Jun 2021 04:58:37 -0700 Subject: [openpgp] Issues from a novice reader X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2021 03:09:42 -0000 --0000000000009694d105c5a26bc2 Content-Type: text/plain; charset="UTF-8" Hi everyone. I've been combing through the working spec as I try to add support for transferring keys into PGP format into a crypto library (the DiceKeys seeded cryptography library) and an app that generates keys from physical randomness (DiceKeys). This is my first time working with PGP keys and with the spec so I have been trying to understand it with a fresh set of eyes. I've filed five issues based on points where I'm genuinely confused. I haven't engaged with an IETF group for over a decade so I hope you'll excuse me if I'm doing so incorrectly. The issues are: #32 : an inconsistency between the number of stated optional fields (4) and actual optional fields (3). #33 : ambiguity about whether checksums are included in a v5 length packet #34 : challenges for the reader to identify which fields changed in v5 packets #35 : ambiguity about whether packet headers are included when a secret-key packet starts with the contents of the corresponding public-key packet. #36 : confusion about if/how one SHOULD self-sign secret keys that cannot themselves be used to create signatures (e.g., EC DH keys) Thanks so much, Stuart Schechter DiceKeys / UC Berkeley --0000000000009694d105c5a26bc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone.

I've been c= ombing through the working spec as I try to add support for transferring ke= ys into PGP format into a crypto library (the DiceKeys seeded cryptography = library) and an app that generates keys from physical randomness (DiceKeys)= .=C2=A0 This is my first time working with PGP keys and with the spec so I = have been trying to understand it with a fresh set of eyes.

<= /div>
I've filed five issues based on points where I'm genuinel= y confused.=C2=A0 I haven't engaged with an IETF group for over a decad= e so I hope you'll excuse me if I'm doing so incorrectly.

The issues are:
=C2=A0 =C2=A0#32: an inconsistency between the num= ber of stated optional fields (4) and actual optional fields (3).

=C2=A0 =C2=A0#33: ambiguity about whether checksums are included = in a v5 length packet

=C2=A0 =C2=A0#34: challenges for t= he reader to identify which fields changed in v5 packets

=C2=A0 =C2=A0#35: ambiguity about whether packet headers are included when= a secret-key packet starts with the contents of the corresponding public-k= ey packet.

=C2=A0 =C2=A0#36: confusion about if/how one = SHOULD self-sign secret keys that cannot themselves be used to create signa= tures (e.g., EC DH keys)

Thanks so much,

Stuart Schechter
DiceKeys / UC Berkeley

--0000000000009694d105c5a26bc2-- From nobody Sat Jun 26 07:40:19 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2915B3A167B for ; Sat, 26 Jun 2021 07:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 Ix3F7NV-Tk81 for ; Sat, 26 Jun 2021 07:40:12 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33403A167A for ; Sat, 26 Jun 2021 07:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=macMIhmODqZbI6yVN22FjCpnoHrN3IQP0mkK9BUpaL0=; b=KJeDqNARfXAytwR9skc2/iRPbn a4XvSzwzyVIyjj9VqTQIwdCENy3MJVkv7Ot8WkH4xivvtiyhS0TNOOxKRIGm/zThP5B1aJoV6Ts7a 3QIxz700SD7DQCD5aEz8ky5sayxL8MxLNCqdeE2DsYK3CbgxYIU7M6AMF2N+gYnQQdAo=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1lx9Tc-0008Ae-GK for ; Sat, 26 Jun 2021 16:40:08 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1lx9Qd-0001aj-HG; Sat, 26 Jun 2021 16:37:03 +0200 From: Werner Koch To: Stuart Schechter Cc: openpgp@ietf.org References: Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Stuart Schechter , openpgp@ietf.org Date: Sat, 26 Jun 2021 16:37:03 +0200 In-Reply-To: (Stuart Schechter's message of "Sat, 26 Jun 2021 11:57:32 +0900") Message-ID: <87sg14k7zk.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=TDYC_Customs_and_Border_Protection_Soros_Spetznaz_Heroin_Red_Cell_CI"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Issues from a novice reader X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2021 14:40:18 -0000 --=TDYC_Customs_and_Border_Protection_Soros_Spetznaz_Heroin_Red_Cell_CI Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi! Thanks for your comments. I am fine using the bug tracker to track the status of a suggestion/bug/feature. For discussion I still believe that the ML list is a better place. So I took the freedom to copy the content of your five reports below. It refer to the lates git HEAD and proabbly not to the last I-D. In fact, we should soon turn to an I-D based discussion again. Shalom-Salam, Werner Here we go: #32 An inconsistency between the number of stated optional fields (4) and actual optional fields (3). Only for a version 5 packet, a one-octet scalar octet count of the next 4 optional fields. There are only 3 optional fields listed below is line about the next 4 optional fields. Is it 3 or is the composite s2k two fields? Example correct values for different situations would be very helpful since it seems like it might be an all-or-nothing thing where the count is used in anticipation of more fields in the future? Also, I found it unclear what optional means here. They are optional because they MAY be included under the stated conditions, or because they MUST be included under those conditions. #33 Ambiguity about whether checksums are included in a v5 length packet - Only for a version 5 packet, a four-octet scalar octet count for the following secret key material. This includes the encrypted SHA-1 hash or AEAD tag if the string-to-key usage octet is 254 or 253. Does it include the two-byte checksum if the material is not encrypted? Also, there's no references to "AEAD tag" elsewhere in the spec, and it wasn't immediately clear that the other references to AEAD were related to this, so I would appreciate clarification. #34 Challenges for the reader to identify which fields changed in v5 packets Help implementers identify changes between packet versions It would be much easier to update code handling V4 packets for V5 if: 1. All uses of "version 4" were followed by (V4) and all uses of "version 5" were followed by "V5". As is, an implementer has to search for both "V5" and "version 5" to try to identify differences. 2. When listing out the contents of V5 packets that are similar to V4 packets, identify those contents that have changed with Only for a version 5 packet or Only for a version 4 packet as is done for the secret-key packet but not other packets. For example, in 5.2.4 (computing signatures), I missed that the length field has been changed from 4 octets to 8 octets because it's buried pages into that section, nine items down on the second of two long unordered lists. #35 Ambiguity about whether packet headers are included when a secret-key packet starts with the contents of the corresponding public-key packet. Clarify whether Secret-Key packets contain Public-Key packets, or just their bodies The packet contains: - A Public-Key or Public-Subkey packet, as described above. In the reference implementation I'm using in trying to create packets, the Secret-Key packet starts off with content mirroring the Public-Key packet, but it is only the packet body. The public-key packet header is not embedded within the Secret-Key packet following the Secret-Key packets header, as would be the case if a packet (not just the packet body) were to embedded within the Secret-Key packet. #36 Confusion about if/how one SHOULD self-sign secret keys that cannot themselves be used to create signatures (e.g., EC DH keys) Clarify self signatures in the context of private keys that can't be used for signing Implementations SHOULD include self-signatures on any User IDs and subkeys Self signatures are defined as follows: A self-signature is a binding signature made by the key to which the signature refers. There is a category of secret keys that can be used for encryption but not for digital signatures (e.g., EC DH keys) and so, by definition, they cannot be self-signed. If I using PGP keys for on-device encryption, and want to store an EC DH key to a file as a transferable secret key, what would I sign the key with any why should I sign it? What would I sign it with? =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=TDYC_Customs_and_Border_Protection_Soros_Spetznaz_Heroin_Red_Cell_CI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSHd0YfKgdOvEgNNZQZzByeCFsQegUCYNc7jwAKCRAZzByeCFsQ empkAP9wnlHF4e/LqvhREvSJ5HXwuZwDxS5oHRBJqMB9IbAyGAEAzCauSMD2VuHM CGZwjmTtEosFPjCzuUzWBqbRijq6cQY= =c6xZ -----END PGP SIGNATURE----- --=TDYC_Customs_and_Border_Protection_Soros_Spetznaz_Heroin_Red_Cell_CI-- From nobody Sun Jun 27 08:11:34 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F1C3A10B8 for ; Sun, 27 Jun 2021 08:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 KBZzzEC51C_i for ; Sun, 27 Jun 2021 08:11:27 -0700 (PDT) Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [180.189.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0C23A10B6 for ; Sun, 27 Jun 2021 08:11:26 -0700 (PDT) Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2168.outbound.protection.outlook.com [104.47.71.168]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-39-w8D219ZnPneIFoicJtxfhA-1; Mon, 28 Jun 2021 01:11:17 +1000 X-MC-Unique: w8D219ZnPneIFoicJtxfhA-1 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com (2603:10c6:10:10b::10) by SYCPR01MB3389.ausprd01.prod.outlook.com (2603:10c6:10:32::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18; Sun, 27 Jun 2021 15:11:10 +0000 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::51a7:5858:c7ef:880f]) by SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::51a7:5858:c7ef:880f%5]) with mapi id 15.20.4264.026; Sun, 27 Jun 2021 15:11:09 +0000 From: Peter Gutmann To: Daniel Kahn Gillmor , "openpgp@ietf.org" Thread-Topic: [openpgp] v5 in the crypto-refresh draft Thread-Index: AQHXXbr+7O9O+mcMl02kzvDvrO7x3asjXH2AgAS1USg= Date: Sun, 27 Jun 2021 15:11:09 +0000 Message-ID: References: , <871r8rwavo.fsf@fifthhorseman.net> In-Reply-To: <871r8rwavo.fsf@fifthhorseman.net> Accept-Language: en-NZ, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [14.1.79.216] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 618be4ee-0661-4cd7-1aee-08d9397dcb78 x-ms-traffictypediagnostic: SYCPR01MB3389: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: GlPkKojLcnpgAiZjjlQaAMMFGaxoAJLE3OWhJm15g2SopKy0dR8l33nZ/xHmOxpyb8fpGYN9wXfaYIBWKKfA61ahx3TUfOapv23P8/lybU0vwejhxEB1EvT0Dgb1DyTTH8scwp+2ycCFGaYRv//LS47CLs/weymdU15uhVfDESlpnhyhuIhhYdfZtKwONPoqb769TOjhz5zuEMOze6E/CU0DT8r/nbI+e3+GvOG0bmpta+fiFN5TvbsWPlqoH4nrL/8nFP9/4SJAjDSqhgxIrjGlc+Z2w6ClmdpZ708G0pho0FNXxzA974dKfIQbQSYkNd+UmEXc+7nBpIp2IAHFWXfXClmKye9du4daSv224cDv/No8Hj34fG2HRCssZjpu6uyx3MkCCCMkm7Dcllb1ZzsfSXbCMGbiv9yVxMt3vM0SX3eFNC3nvENP7/5ztiQMp9XdXbMpZ+mctp0H+5qOnqQBITfVZ+F16InKYZ8eErkMQ1225USfsTYLUuZhXbxYsmLabybfq01CWQfbukQEkExqBFdxkZ6NVYWG1NRol3BIZWD1f7MIb30l7RmOemZPhSwMShVKXttDJZIbfieBnt7CDTdKz4lOong8E5S9J/b/ZwrvjIguf2XzE4qrdnwO7XiXgEVubbQHUQ38ky+Alg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6251.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(366004)(376002)(396003)(39860400002)(64756008)(66446008)(86362001)(66556008)(66476007)(66946007)(8676002)(186003)(316002)(8936002)(786003)(2906002)(9686003)(52536014)(76116006)(55016002)(53546011)(478600001)(110136005)(6506007)(122000001)(26005)(5660300002)(38100700002)(33656002)(71200400001)(7696005)(83380400001)(2004002); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?n6BtBLriRMPKhS5236NZYcXfcI+7PnkBasCS6gcTGRnR5T4gdx2ekXjm?= =?Windows-1252?Q?RkqBSFpfmhW10WNirXMf67de33vyywBVJkGIXZUJvo8mo6+Mw1zaz/+R?= =?Windows-1252?Q?ibiy9NYT8OvdaPv80sX/qkcHMVlexH1sYiAhgYcZWwHU9F2PwBwot0Pn?= =?Windows-1252?Q?IltBINvUUVNRCE+N2dqpi4s1T/WEdN4ZUgEJERAE63d5v3LoFt3rK5CL?= =?Windows-1252?Q?TwLawzs7re9tn2FWtjYA3PFcLftBOegH6l2F2cIqm1mA9I24U0N5qyFz?= =?Windows-1252?Q?OpXLXO9S7co5HVmaqE0eQlcydxJaEftLegWhBh8M8CKtlZStSOrPjrUs?= =?Windows-1252?Q?CAmCGjwQwLEnO44/u3q7QOGs6BaQ4A9PXIGAbKlfG7RZeAyKeNcPKglX?= =?Windows-1252?Q?wZDtSRwgQHLPVCfUtQX0DeJNvhxW0s4Y1MJWHvv/eLQTmc34NahMv/ao?= =?Windows-1252?Q?co0VUDGINYGbFgwrwEqoxMYpin4PXeaJ7vzpgyB22vf6pBTDLPrRHXF+?= =?Windows-1252?Q?aLigf1H6f7K9CrlUrmCApqsZUyvhxBFgjwFJts8pJKDW2LNNm5tD1NQg?= =?Windows-1252?Q?OY0489wv1DbttcQZWCoLsr7yUuUR/k+EwCPxiia7/YJS3waKuGVrz8vY?= =?Windows-1252?Q?OdBVZA5VaGeNRkjzjioHH/+PMZhNkr6WD/Wr9PjmVaCUmnWnBf9+7Q1R?= =?Windows-1252?Q?yj50ULQqR9h0MvOBFnEzpR5P7lLjoE17iEF5f6VQo92vdttq3kpQaI3f?= =?Windows-1252?Q?S35lCjpEF2xSpyjz1lmv7qZF/C5ohHdsp0qXQx7eFlC0WT1suaJVWIhH?= =?Windows-1252?Q?7LcwK4308cobnIm6UXG7YU3EO9uKxLIb0prI0RNxIyrD7GILeh75Vr6J?= =?Windows-1252?Q?5mq4GQyOIXDopgKNts0vFzCJgT5g5UIlQZgU230cEXU/bv6vKbhEGrNf?= =?Windows-1252?Q?2LhPpx1+Fvm7EwzLlTjnlN/y+Ji82Cnr5UyPrtqE+PlG0GIAbXQqUweN?= =?Windows-1252?Q?BVFyR03EKXxvdmw0rfDJSm6Ly9OS+BmJ5u8pVudvvtltYTuLqxfCRIkj?= =?Windows-1252?Q?Kjnz+5fUMEoHlItr7JJVlcg/ft8J9GaGBHVQpwRG4DGp/hCeiwIJvOiC?= =?Windows-1252?Q?ickGtG1lrlbhcdpMQ9voJeu4RgIyS7RoctP8lJDvZVKXfzJuFy7+nA50?= =?Windows-1252?Q?7QTbb58pkeYPyPTwvGwi8I9gsvdcrNsnUfFFO08uR9PWZw/dNg31Is98?= =?Windows-1252?Q?0FR2NAcGTmyaEOl29G/Zkwd6+8/x88SWnEs6e1CB+GtfS/xnbOLBftkl?= =?Windows-1252?Q?nePyfvNg/FYKAqYXFX7wV/tZLgXwewP5uEo1K90EnsxBDjBPas6AXS3M?= =?Windows-1252?Q?uoAcX7MLlzW7yr6r/rXM0n7jdrzGIicgg4Q=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6251.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 618be4ee-0661-4cd7-1aee-08d9397dcb78 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2021 15:11:09.1640 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +39NCwLGZ4K/hxD4/rtDuO+ffNfg6e70oE/jrqVUE0r/qABuF4o8/R6lWBuVBYOX3ssWXg73GLaGRQSDdwaGYmaab/dr4bvDIeMpDYjS4zs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYCPR01MB3389 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cs.auckland.ac.nz Content-Language: en-NZ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2021 15:11:32 -0000 >I would welcome a proposal for brief text that describes this use for the= =0A>revision of RFC 4880=0A=0ADo you mean the -bis draft or the -refresh dr= aft? If it's the -refresh draft=0Ado you have the current text covering fi= ngerprints? The posted draft -03=0Apredates the current discussion.=0A=0AP= eter.=0A=0A=0A________________________________________=0AFrom: openpgp on behalf of Daniel Kahn Gillmor =0ASent: Friday, 25 June 2021 03:16=0ATo: openpgp@ietf.org=0ASubject: R= e: [openpgp] v5 in the crypto-refresh draft=0A=0AOn Thu 2021-06-10 05:40:34= +0000, Peter Gutmann wrote:=0A> Daniel Kahn Gillmor writes:=0A>=0A>>Key ID= or fingerprint comparison has been recommended in the past by the=0A>>Open= PGP community as a reasonable way that one communications peer can=0A>>conf= irm that they have the "right key".=0A>=0A> Ah, good point, so it's a human= -factors thing rather than just (say) mapping=0A> a signature to the key th= at signed it, where even if you can create a=0A> collision to point to a di= fferent key the signature check will still fail.=0A>=0A>>which i'll call th= e "comparison-verification" practice:=0A>=0A> Is it worth mentioning this i= n the text? The current text just says "this=0A> thing is the fingerprint"= with an implicit use elsewhere in the doc of=0A> "the thing used to identi= fy which key is being used", without mentioning its=0A> second, non-protoco= l use, to verify someone's key.=0A=0AI would welcome a proposal for brief t= ext that describes this use for=0Athe revision of RFC 4880, though i think = a full description of=0Afingerprint-based verification (and other alternati= ves for key=0Aconfirmation) is probably beyond the scope for the crypto ref= resh=0Adocument. It gets complicated, and the best practices are still pre= tty=0Aunclear.=0A=0A> (Is this still done? When was the last time someone = here attended a key=0A> signing party?).=0A=0AYes, it is "still" done, thou= gh i'm not sure it's ever been done to the=0Aextent that the OpenPGP commun= ity has traditionally imagined it would=0Abe. "key signing party" is not t= he only context, either. i've got=0Adozens of business cards or small slip= s of paper which contain OpenPGP=0Afingerprints (either as text or as QR co= des) that people have given me=0Aat free software conferences, and i've giv= en them out myself.=0A=0Ado people *actually* verify them effectively? tha= t's another story=85=0A=0A --dkg=0A From nobody Mon Jun 28 02:05:38 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19313A3230 for ; Mon, 28 Jun 2021 02:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com 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 ZWCiH8gg-rl2 for ; Mon, 28 Jun 2021 02:05:32 -0700 (PDT) Received: from mail-4317.protonmail.ch (mail-4317.protonmail.ch [185.70.43.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79273A3232 for ; Mon, 28 Jun 2021 02:05:31 -0700 (PDT) Date: Mon, 28 Jun 2021 09:05:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1624871129; bh=H67Kisx/pl91N9QStBcvLMcP/CHbYsH/VL+HfFIv1zM=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=TneQcgYi2lKyiDTbbn1swHrWGZ3VTnXkBSQAW5Qm9gxO3CZPZmpSut3P3vk1rFd2a 7NAEK1szCHTwb1w8wOB/czqd7hk+IfCtLAjSjWybSD1hKj+2tmGqst5AYqyYkROYd/ J+WfoaT9edoCYbJBCuxrz0FVkVCH/et/qNUTJcj0= To: Daniel Kahn Gillmor From: Daniel Huigens Cc: Kai Engert , openpgp@ietf.org Reply-To: Daniel Huigens Message-ID: In-Reply-To: <87y2azuv8a.fsf@fifthhorseman.net> References: <87y2azuv8a.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] German BSI, PQC for OpenPGP in Thunderbird, X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 09:05:37 -0000 Hi all, For what it's worth, we (ProtonMail) were also planning to create an experimental implementation of post-quantum crypto in OpenPGP, sometime this fall - not intending to "create a standard", rather our rationale was that an experimental implementation could teach us something about a potential standardization in the future. That being said, if the WG is ready for this work by then, we are of course happy to contribute to that work, and collaborate on a potential standardization while working on an experimental implementation. Depending on when someone applies to this tender from the BSI, perhaps they could do the same. While it's of course up for debate, we had a similar set of algorithms in mind to use for the experimental implementation (using a hybrid approach of both post-quantum and classical algorithms). We do think that it makes more sense to wait for NIST standardization for the final standardization of PQC in OpenPGP - but even if the set of standardized algorithms ends up being different, the high-level work might still teach us something, so we are in principle not opposed to this work. If someone applies to this tender before the WG is ready for this work, we would hope / recommend that they take a similar approach as we were planning, and create an experimental implementation that could inform, but not define, the final specification. That being said, as soon as this WG has the bandwidth to work on this, hopefully the person working on that could join the WG and help draft a specification, and as I said we would be happy to contribute to that effort as well. Best regards, Daniel Huigens From nobody Mon Jun 28 02:55:19 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928223A337D for ; Mon, 28 Jun 2021 02:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 R0lvbMHuXzdR for ; Mon, 28 Jun 2021 02:55:12 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831AE3A337C for ; Mon, 28 Jun 2021 02:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=hwJYCF7rDW7/7o8dhm1M3uKorULUNlsWa4MsNJvMFyY=; b=LZM0PXoPsPVzbQt05jm+GA4JCC 1Vk6h8eJ4M4lzuCdI6puU5juzxli/zRrswASTgnaj+i31IhYvLSCxRmzsywUs3yMs3Oh4L+orEm0O oyuHnBkPS7yAlNF9K6eB0KQmfPNX++Z0drCYgBUzIS1DWWJeAg2hnYQwz+U2dU4P26hA=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1lxnyu-00036W-Q4 for ; Mon, 28 Jun 2021 11:55:08 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1lxnuD-0004vs-9H; Mon, 28 Jun 2021 11:50:17 +0200 From: Werner Koch To: Daniel Huigens Cc: Daniel Kahn Gillmor , Daniel Huigens , openpgp@ietf.org, Kai Engert References: <87y2azuv8a.fsf@fifthhorseman.net> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Daniel Huigens , Daniel Kahn Gillmor , Daniel Huigens , openpgp@ietf.org, Kai Engert Date: Mon, 28 Jun 2021 11:50:11 +0200 In-Reply-To: (Daniel Huigens's message of "Mon, 28 Jun 2021 09:05:27 +0000") Message-ID: <87czs6jp2k.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=distributed_denial_of_service_al-Qa'ida_AGT._AMME_Abbas_counter=terr"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] German BSI, PQC for OpenPGP in Thunderbird, X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 09:55:18 -0000 --=distributed_denial_of_service_al-Qa'ida_AGT._AMME_Abbas_counter=terr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 28 Jun 2021 09:05, Daniel Huigens said: > If someone applies to this tender before the WG is ready for this work, > we would hope / recommend that they take a similar approach as we were FWIW, the tender is designed for a timeframe of 3 years with a strict set of milestones and implementation can't be done before the other work items have been finished. Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=distributed_denial_of_service_al-Qa'ida_AGT._AMME_Abbas_counter=terr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSHd0YfKgdOvEgNNZQZzByeCFsQegUCYNmbUwAKCRAZzByeCFsQ esoVAQCOGY1z7Xy7vDFOs4t2kVA5MtUJ5hOFIb0aksbL2Hf6lAD/XD5efs15zF2e Daq/eJqj8r/Wc6tCa21+3BPmXCis0Ak= =fJhf -----END PGP SIGNATURE----- --=distributed_denial_of_service_al-Qa'ida_AGT._AMME_Abbas_counter=terr-- From nobody Mon Jun 28 03:36:28 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37D53A3476 for ; Mon, 28 Jun 2021 03:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 LPuzHwprJlaY for ; Mon, 28 Jun 2021 03:36:22 -0700 (PDT) Received: from harrington.uberspace.de (harrington.uberspace.de [185.26.156.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7893A347D for ; Mon, 28 Jun 2021 03:36:21 -0700 (PDT) Received: (qmail 2448 invoked from network); 28 Jun 2021 10:36:19 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by harrington.uberspace.de with SMTP; 28 Jun 2021 10:36:19 -0000 From: Justus Winter To: Alessandro Barenghi Cc: openpgp@ietf.org In-Reply-To: References: Date: Mon, 28 Jun 2021 12:36:17 +0200 Message-ID: <8735t246ou.fsf@europ.lan> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] German BSI, PQC for OpenPGP in Thunderbird, X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 10:36:27 -0000 --=-=-= Content-Type: text/plain Alessandro Barenghi writes: > An interesting bird's eye view on the sizes of ciphertexts/keypairs > and speed of the current third round candidates is available here[**] > (from slide 100 onwards). > > [**] https://csrc.nist.gov/CSRC/media/Projects/post-quantum-cryptography/documents/round-3/seminars/oct-2020-gaj-kris-presentation.pdf That is a great pointer. I think from the perspective of the protocol, the biggest challenge is that OpenPGP can only express cryptographic artifacts up to 2^16 bits, or 2^13 bytes. Even if we assume that artifacts like keys, ciphertexts, signatures are just comprised of a single component, that only impacts very few KEMs (HCQ, FrodoKEM, and of course McEliece), of which only McEliece is a 3rd round finalist. But, given that all other finalists are based on structured lattices, and NIST expects to select only one of those, McEliece may very well be one of the selected algorithms. It's a different picture for the signature schemes, though, where only Falcon and Dilithium fit into OpenPGP's MPI envelope, both of which are 3rd round finalists. The signature schemes seem to all trade off key size vs. signature size, with only two schemes barely able to fit into MPIs. That is a bit disconcerting. NIST seems to think so too, as they are interested in more candidates. I think we should revisit the way we store cryptographic artifacts in OpenPGP. Unfortunately, neither SOS nor SBS address the issue of potentially large PQ artifacts. Justus --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFLBAEBCAA1FiEEJWpOVeSnLZetJGjniNx+MzhfeR0FAmDZpiEXHGp1c3R1c0Bz ZXF1b2lhLXBncC5vcmcACgkQiNx+MzhfeR0qpAgAsz6apASYVl6dOQk0mWeccqat HnbSh7ddFbY0GDYGRQwGO/nuVIVgi8+FV/AHMob7sEZEgtHTORzRGq63WMdngifO o1OMT+7oEsU3tel/QIXmCgFJvnBiMUEeHZR88OIOOKky5eTmu8qC9p1HsMMxBAxt GKDbHXA6Sxr3ZnYip7ouo8Zuaw1nUz1XaBVNhKzjv8WYqrBpNndgz1oscAxt9u/5 lh7RTvDnD7eLOOjDMqGfJF+l52ErZACfpWYepuDmh9vtaSkdaYV/eI0ZEGQ+AR4V sncvrz+HLigHAEDLyNij87mERvJBE+acRvUlxn8AzdJpKpiIUFIR51IQt6QRsw== =h046 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 28 06:53:01 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290AD3A07E1 for ; Mon, 28 Jun 2021 06:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.338, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kuix.de 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 NVnYjm1PZvvG for ; Mon, 28 Jun 2021 06:52:55 -0700 (PDT) Received: from cloud.kuix.de (cloud.kuix.de [IPv6:2001:8d8:1801:86::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A2F33A07DB for ; Mon, 28 Jun 2021 06:52:55 -0700 (PDT) Received: from [10.137.0.17] (p5dcf40f9.dip0.t-ipconnect.de [93.207.64.249]) by cloud.kuix.de (Postfix) with ESMTPSA id 71E051906AD; Mon, 28 Jun 2021 13:52:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kuix.de; s=2018; t=1624888370; bh=d8VFHFlOHCklRj8NyAbR1KVgCMhpy2hQwDy71VXH7CA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=YNCELEi6b+BEitJZr0f0dRjKEJSS9apwVIg3t4nuMpzsOy67kXXrB2pXnClVQNd0c 5HjVpZIQY1yQrDEFMJwC6zjbYNLHNNZIzsbPHbJrlLDuB9uO/iCZ7OYOLRNy5oaZS1 hyuO9MJ0asZ/jHgVTI4m8erIKAcD7kinmBAVLn3l+37Znplr4iMKB9HAl7+aCRVPM9 VrtlDvvUmTSTED7kLsvn7TQOAe8yePeOCLMv0GYQE2GmTqV/Xbb8ayhbZh2pFz2hBz N3TRtZcNYQ/C7pKEf42Y766Ufzx90nRujnOf8QwPZqxPsy/J6ZI47NCzh0nVxQfHiS RT02SaNmd92Ag== To: Daniel Huigens , Daniel Kahn Gillmor , Daniel Huigens , openpgp@ietf.org References: <87y2azuv8a.fsf@fifthhorseman.net> <87czs6jp2k.fsf@wheatstone.g10code.de> From: Kai Engert Message-ID: <586f7cdc-4aa6-48cc-aa47-5a7970b29c08@kuix.de> Date: Mon, 28 Jun 2021 15:52:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.11.1 MIME-Version: 1.0 In-Reply-To: <87czs6jp2k.fsf@wheatstone.g10code.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] German BSI, PQC for OpenPGP in Thunderbird, X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 13:53:00 -0000 FYI, Werner's message fails to render in Thunderbird, because of the use of an apostrophe character in the MIME boundary. I've filed the issue here: https://bugzilla.mozilla.org/show_bug.cgi?id=1718533 Kai From nobody Mon Jun 28 07:14:25 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15F63A0977 for ; Mon, 28 Jun 2021 07:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=67JJOW6R; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=ZT7i7cm/ 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 n53QHyxQG4j7 for ; Mon, 28 Jun 2021 07:14:11 -0700 (PDT) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F1C3A0994 for ; Mon, 28 Jun 2021 07:14:10 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1624889649; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=MAvrIzwfBMVVhpgO4xeC/i6T64UkXjDcvm9mZiEfipA=; b=67JJOW6REURoRDIczOMSP8+uotXh1W8Rn9uNN33IFIyNXMtY1H1YQUGcQA8i7u/qKRHQh TeztrGhos5NVp/oCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1624889649; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=MAvrIzwfBMVVhpgO4xeC/i6T64UkXjDcvm9mZiEfipA=; b=ZT7i7cm/EBE982DaH8L6M+DE11BSRdtGmHdECZnSh5nUF9kk0NYZqaPUfrNhaYZ6yqbeF KySl2lZQkRQvGhKwVrzL/SpNqZa9xoDP2YKbTzkxGkCR2+44JRq5I7GWwgyliesPzL1Q4dA xxv3SwcHzzxSUOXpgPggYvccH/R0EV7kuCt9Mo1TeM7hOEVy3BdVXjq9cfUmWb9R5gYcwWx 2wwyXgAmkQBBgNTwMiV6CsNOtJ1U7/KiYBVfyCT0yH5g2JDNtRf7n1bs0Sxa0oiXTCe1xfX tyoBSjEtl/26ij6db0zDsWQ1RWJuUyvNkTfXbgC8sirUPtPyZ+UbV++bDiDQ== Received: from fifthhorseman.net (c-73-106-144-119.hsd1.ga.comcast.net [73.106.144.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 1C6FBF9A5; Mon, 28 Jun 2021 10:14:08 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 6D8D2203D8; Mon, 28 Jun 2021 09:25:48 -0400 (EDT) From: Daniel Kahn Gillmor To: Peter Gutmann , "openpgp@ietf.org" In-Reply-To: References: <871r8rwavo.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Mon, 28 Jun 2021 09:25:46 -0400 Message-ID: <87zgvat92d.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] v5 in the crypto-refresh draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 14:14:25 -0000 --=-=-= Content-Type: text/plain On Sun 2021-06-27 15:11:09 +0000, Peter Gutmann wrote: >>I would welcome a proposal for brief text that describes this use for the >>revision of RFC 4880 > > Do you mean the -bis draft or the -refresh draft? If it's the -refresh draft > do you have the current text covering fingerprints? The posted draft -03 > predates the current discussion. the crypto-refresh draft is the one that is currently being edited. and yes, -03 does indeed predate the current discussion -- the discussion is *about* the changes that were included in -03. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYNnN3AAKCRA+nXFzcd5W XNEoAP9VTqMZTyHMDgTAu8PgiVpnwklTT76xtQ1CG8wDRh4GFgD/UDPDybo9tYob s2445j1VYr5yAPkBKVe7VdYk/wg8fAs= =2L1l -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 28 07:26:38 2021 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA8C3A0A1C for ; Mon, 28 Jun 2021 07:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=Om4TvlA9; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=vM5hGhTD 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 YPDxr556__TH for ; Mon, 28 Jun 2021 07:26:31 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9308C3A0A20 for ; Mon, 28 Jun 2021 07:26:31 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1624890389; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=GPMKr1iUrC9BbjyGy9PjR2nmeNY+GHwcexFX68/MTCM=; b=Om4TvlA98vzzAkZWsP1VwVWtgpN8CHegfWig3LB3c6jOU87qS4bed9CD0JtDOaf0hitXg UEcCCbrVP3z+vplDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1624890389; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=GPMKr1iUrC9BbjyGy9PjR2nmeNY+GHwcexFX68/MTCM=; b=vM5hGhTDyMEZLRWiL3H+UjwaXVbHRfuEStLCzz2KxSGL3ZyLwCGTvBIY3k83XsOUOsrLE 11avZ7uvd6ms0uZEvs2gDTlA3U4Y3bky3b6jAaJlDdnvXy70SY9cqMfddrkOuJdU1J+YFd/ 9N2Y2p5HOn/phdnhVT4za6hgw5dgQT1XCrzx1G2jn2noi5asZONR+8qaZzFxZ//Z6Zkan6f +Xs/5xrddOGPXTIzmTQdtcU3SfgXtru2paisgBhP2+uM0SYKUnx6MnMuitP3/y5xSaCEQtv S8M2k+EUAebvk7+1mhiu8yoINdOog7MciVYKg7SnCuRJb8jLjeCNBeImpWVQ== Received: from fifthhorseman.net (c-73-106-144-119.hsd1.ga.comcast.net [73.106.144.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 0361DF9A5; Mon, 28 Jun 2021 10:26:28 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 80270203D8; Mon, 28 Jun 2021 10:26:26 -0400 (EDT) From: Daniel Kahn Gillmor To: Justus Winter , Alessandro Barenghi Cc: openpgp@ietf.org In-Reply-To: <8735t246ou.fsf@europ.lan> References: <8735t246ou.fsf@europ.lan> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Mon, 28 Jun 2021 10:26:24 -0400 Message-ID: <87wnqet69b.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] German BSI, PQC for OpenPGP in Thunderbird, X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 14:26:36 -0000 --=-=-= Content-Type: text/plain On Mon 2021-06-28 12:36:17 +0200, Justus Winter wrote: > I think we should revisit the way we store cryptographic artifacts in > OpenPGP. Unfortunately, neither SOS nor SBS address the issue of > potentially large PQ artifacts. As the person who coined "SBS", I want to note that it is *not* intended to be a design that will work for future algorithms. It's merely a handle to describe the particular idiosyncratic structure used in some cases already for 25519. While SBS is "MPI-like", we already do have non-MPI-like data structures stuffed into the "algorithm-specific" parts of some key material: in particular, the ECC OID is encoded with a single octet length, which means it cannot be parsed correctly by any implementation that is ECC-ignorant but blindly expects to extract a series of MPI-like objects from a public key packet. For future algorithms (including anything PQ) i'd hope that the future spec would explicitly declare a distinct data structure for the algorithm as necessary. I don't think we need a generic data structure format given the range of possible requirements. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYNncEgAKCRA+nXFzcd5W XHsWAP4gsWh/Hs8oXEDcgZwTsoehm8AyjKk6+MqeDrmMQBJYkAD/eljGf0b2QPmW ydZWRgR0Ii1Ypevi/fIl4a2QoHcJzww= =vcGu -----END PGP SIGNATURE----- --=-=-=--