Subject: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt

From: [email-masked]
Date: Fri, 05 Feb 2021 09:23:26 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Specification for Pretty Good Privacy WG of the IETF.

        Title           : OpenPGP Message Format
        Authors         : Werner Koch
                          Paul Wouters
	Filename        : draft-ietf-openpgp-crypto-refresh-01.txt
	Pages           : 94
	Date            : 2021-02-05

Abstract:
   { Work in progress to update the OpenPGP specification from RFC4880 }

   This document specifies the message formats used in OpenPGP.  OpenPGP
   provides encryption with public-key or symmetric cryptographic
   algorithms, digital signatures, compression and key management.

   This document is maintained in order to publish all necessary
   information needed to develop interoperable applications based on the
   OpenPGP format.  It is not a step-by-step cookbook for writing an
   application.  It describes only the format and methods needed to
   read, check, generate, and write conforming packets crossing any
   network.  It does not deal with storage and implementation questions.
   It does, however, discuss implementation issues necessary to avoid
   security flaws.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-openpgp-crypto-refresh-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Wouters <[email-masked]>
Date: Fri, 5 Feb 2021 12:55:20 -0500 (EST)

On Fri, 5 Feb 2021, [email-masked] wrote:

> Subject: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt

> https://www.ietf.org/rfcdiff?url2=draft-ietf-openpgp-crypto-refresh-01

You can also look at the working group git repository. The changes in
this document are:

     Update introduction
     Update version terminology around old PGP versions.
     normalize punctuation and capitalization
     refer to SHA2 hash algos as SHA2-XXX, not SHAXXX
     Fix erratum 2271
     Fix erratum 2270
     Fix erratum 3298
     Fix erratum 2242
     Merge Camellia references (obsoleting RFC 5581)
     Identify RSA Sign-Only by algorithm number
     Drop unused reference to RFC 1423
     drop unused reference to MAURER
     normalize on upper-case hexadecimal
     clarify blank lines and whitespace

These changes should only represent what the WG previously thought it
had reached consensus on. If you see anything where you think this might
not be the case, please discuss that on the list here. If you have read
the -01 (and -00) version and it all looks good, feel free to also let
us know here on the list.

Paul & Werner

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 5 Feb 2021 19:14:35 +0000

Thanks Paul and Werner!

On 05/02/2021 17:55, Paul Wouters wrote:
>   If you have read

Yes please - it'd be good to get a few such mails, so
we know people are checking and all seems well. About
4 or 5 acks should be plenty if nobody finds problems.

Thanks,
S.

---

From: Heiko Stamer <[email-masked]>
Date: Sat, 6 Feb 2021 21:14:52 +0100

Hey,

I have a question regarding the change at page 59, line 28:

"The blank line can either be zero-length or contain only whitespace,
that is spaces (0x20), tabs (0x09) or carriage returns (0x0d)."

For spaces and tabs the intention is clear for me, however, I am not
sure about carriage returns in general. According to Unicode Character
Database there are some other whitespace characters, e.g., form feed
(0x0c). Should such characters be included, too?

I am fine with this change, however, at least for DKGPG we have to
adjust some lines of source code.

Best regards,
Heiko.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Feb 2021 17:31:37 -0500

looks good to me.

    >> https://www.ietf.org/rfcdiff?url2=draft-ietf-openpgp-crypto-refresh-01

SHA224     | 0x30, 0x31,
->
SHA224     | 0x30, 0x2D

looks like an errata fix?  (Table 5) I looked in gitlab briefly, but I didn't see this
change quickly.   Otherwise SHA224 is identical to SHA2-256, I think.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Heiko Schaefer <[email-masked]>
Date: Sat, 6 Feb 2021 23:38:49 +0100

> change quickly.   Otherwise SHA224 is identical to SHA2-256, I think.

I had also wondered about that. The changes seems to be from

https://www.rfc-editor.org/errata/eid2270

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 7 Feb 2021 10:25:40 +0000

Heiko Stamer <[email-masked]> writes:

>For spaces and tabs the intention is clear for me, however, I am not sure
>about carriage returns in general. According to Unicode Character Database
>there are some other whitespace characters, e.g., form feed (0x0c). Should
>such characters be included, too?

That also just seems wrong in general, the last major OS type I know of that
used CR delimiters was Mac OS from 1984.  Shouldn't this be LF or CRLF?
Wherever this came from, it's not in 4880, or any other common RFC that
defines a format for blank lines.

Peter.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 7 Feb 2021 17:41:07 -0500 (EST)

> defines a format for blank lines.

Question for the WG. Should we change the text to make the entries
"examples" of white space, or should we add a definition of white space?

If the latter, what do the current openpgp implementations define as
white space characters right now?

Paul

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 8 Feb 2021 05:09:15 +0000

Paul Wouters <[email-masked]> writes:

>Question for the WG. Should we change the text to make the entries "examples"
>of white space, or should we add a definition of white space?
>
>If the latter, what do the current openpgp implementations define as white
>space characters right now?

I think the better option is to not reinvent any definition and possibly get
it wrong but to refer to relevant RFCs that have been around forever and are
widely accepted.  In this case it'd be something PEM-related, for classic PEM
there's RFC 1421, but I think more relevant, and recent one is 7468, all you'd
need to do there is add new definitions for the PGP messages.

Peter.

---

From: Andrew Gallagher <[email-masked]>
Date: Mon, 8 Feb 2021 10:50:02 +0000

> defines a format for blank lines.

It reads to me like this change is intended to cover a "blank line" of 
assorted spaces and tabs, with an optional trailing carriage return 
before the line feed delimiter. The admission of carriage returns 
elsewhere in the whitespace sequence is surely unintentional.

Note that the similar definition of "trailing white space" on line 69 
should be kept consistent with that of "blank line".

-- 
Andrew Gallagher

---

From: Andrew Gallagher <[email-masked]>
Date: Mon, 8 Feb 2021 10:55:36 +0000

> should be kept consistent with that of "blank line".

Page 69, sorry. :-(

-- 
Andrew Gallagher

---

From: Guillem Jover <[email-masked]>
Date: Thu, 11 Feb 2021 16:51:07 +0100

On Mon, 2021-02-08 at 10:50:02 +0000, Andrew Gallagher wrote:
> assorted spaces and tabs, with an optional trailing carriage return before
> the line feed delimiter. The admission of carriage returns elsewhere in the
> whitespace sequence is surely unintentional.

Yes this was the intention, as prompted by:

  <https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=aea291e3db1ac0414dcf005a0a607e78bdd77a5e>

The original MR:

  <https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/6>

> Note that the similar definition of "trailing white space" on line 69 should
> be kept consistent with that of "blank line".

Ah probably missed that one.

Thanks,
Guillem

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 15 Feb 2021 18:56:34 -0500

> Ah probably missed that one.

Thanks for this discussion, all.

It seems clear to me that the text about whitespace that was merged into
-01 doesn't have WG consensus at the moment -- iiuc, it may address the
original concern raised by Guillem, but is unintentionally overbroad,
and might introduce further incompatibilities between implementations if
they try to follow the spec as written.

I propose the way forward for this is for now, we revert those changes,
and the next revision (-02) could retain the language about whitsepace
from RFC4880.  I've proposed that here:

    https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/33

(see also the attached diff)

In the meantime, so we don't lose sight of the legitimate problem that
Guillem wants addressed, I've opened
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/11

If someone from the group wants to propose alternate text that addresses
the issue but doesn't introduce the inconsistencies identified by Andrew
and others, then please propose that text on-list here (in a different
thread?)  -- and if you can also make it as a merge request on gitlab
that'd be a bonus.

Regards,

   --dkg

From 0bf360cfc448211a85b287e2728b0a5792ba851d Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 15 Feb 2021 18:33:30 -0500
Subject: [RFC4880bis PATCH] Revert "clarify blank lines and whitespace"

This reverts commit d343098838f7ef22df16dc187163417a7d0733e4.

[Discussion on the mailing
list](https://mailarchive.ietf.org/arch/msg/openpgp/AvsVX6SREEstygUHzHNjps40vq0/)
suggest that the changes in that commit don't have full consensus, and
indeed even the original author of the changes appears to acknowledge
that the definition doesn't cover the specific ground it intends to
cover.
---
 crypto-refresh.md | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/crypto-refresh.md b/crypto-refresh.md
index 7e17b6f..3616585 100644
--- a/crypto-refresh.md
+++ b/crypto-refresh.md
@@ -1989,7 +1989,7 @@ Concatenating the following data creates ASCII Armor:
 
 - Armor Headers
 
-- A blank line
+- A blank (zero-length, or containing only whitespace) line
 
 - The ASCII-Armored data
 
@@ -2024,7 +2024,7 @@ BEGIN PGP SIGNATURE
 
 Note that all these Armor Header Lines are to consist of a complete line.
 That is to say, there is always a line ending preceding the starting five dashes, and following the ending five dashes.
-The header lines, therefore, MUST start at the beginning of a line, and MUST NOT have text other than whitespace --- space (0x20), tab (0x09) or carriage return (0x0d) --- following them on the same line.
+The header lines, therefore, MUST start at the beginning of a line, and MUST NOT have text other than whitespace following them on the same line.
 These line endings are considered a part of the Armor Header Line for the purposes of determining the content they delimit.
 This is particularly important when computing a cleartext signature (see below).
 
@@ -2071,8 +2071,6 @@ Currently defined Armor Header Keys are as follows:
   In such instances, an implementation MAY override the UTF-8 default by using this header key.
   An implementation MAY implement this key and any translations it cares to; an implementation MAY ignore it and assume all text is UTF-8.
 
-The blank line can either be zero-length or contain only whitespace, that is spaces (0x20), tabs (0x09) or carriage returns (0x0d).
-
 The Armor Tail Line is composed in the same manner as the Armor Header Line, except the string "BEGIN" is replaced by the string "END".
 
 ## Encoding Binary in Radix-64 {#encoding-binary-radix64}
@@ -2189,7 +2187,7 @@ The cleartext signed message consists of:
 
 - One or more "Hash" Armor Headers,
 
-- Exactly one blank line not included into the message digest,
+- Exactly one empty line not included into the message digest,
 
 - The dash-escaped cleartext that is included into the message digest,
 
@@ -2219,7 +2217,7 @@ The line ending (i.e., the \<CR>\<LF>) before the `-----BEGIN PGP SIGNATURE-----
 
 When reversing dash-escaping, an implementation MUST strip the string `- ` if it occurs at the beginning of a line, and SHOULD warn on `-` and any character other than a space at the beginning of a line.
 
-Also, any trailing whitespace --- spaces (0x20), tabs (0x09) or carriage returns (0x0d) --- at the end of any line is removed when the cleartext signature is generated and verified.
+Also, any trailing whitespace --- spaces (0x20) and tabs (0x09) --- at the end of any line is removed when the cleartext signature is generated.
 
 # Regular Expressions {#regular-expressions}
 
-- 
2.30.0

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 15 Feb 2021 19:10:59 -0500

On Fri 2021-02-05 19:14:35 +0000, Stephen Farrell wrote:
>> If you have read the -01 (and -00) version and it all looks good,
>> feel free to also let us know here on the list.
>

I'm glad to see that several people in the WG appear to have reviewed
the diffs with reasonable attention to detail.

From what i can see, the only concerns raised were about subtle (and
potentially problematic) changes about the definition of whitespace for
ASCII-armored text, which probably shouldn't have made it into -01 .
The initial inclusion was my mistake -- in trying to help formulate a
set of changes that were minor textual changes, i shouldn't have
included it.  I've proposed dropping that set of changes from the draft
for now (hopefully someone can provide a cleaner fix).

Just a reminder here to please ack if you've read the changes -- and to
raise concerns if you've got them.  I'm grateful for the participation,
and think we should keep it going!

        --dkg

---

From: Werner Koch <[email-masked]>
Date: Tue, 16 Feb 2021 10:11:02 +0100

> -01 doesn't have WG consensus at the moment -- iiuc, it may address the

The problem with such minor changes is that they require extensive
interop tests.  Back when we started with OpenPGP we had to tweak these
things a lot until all 3 implementations were interoperable.

If we really want to make the definition more strict, lets do this after
all chartered changes have been done.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 16 Feb 2021 12:08:01 -0500

> things a lot until all 3 implementations were interoperable.

yep -- this is a great place to apply an interop test.

I note that there are some "linebreak normalization tests" at the tests
that use SOP:

   https://tests.sequoia-pgp.org/#Detached_signatures__Linebreak_normalization

this contains some un-colored rows where you can see incompatibility
between implementations, and where neither proposed text offers guidance
as to which should be preferred.

Anyone proposing a future textual change to try to improve the situation
should take a look at that list.  Proposals for additional cases to test
would also be useful.

> all chartered changes have been done.

I agree that solving this problem isn't higher urgency than the
chartered text, which is why i've proposed reverting to the text from
RFC 4880 and opened https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/11
to track it in our backlog.  (i've tagged it with the "unchartered"
label as a reminder)

          --dkg

---

From: [email-masked]
Date: Tue, 16 Feb 2021 14:29:19 -0500

On 2/16/2021 at 12:08 PM, "Daniel Kahn Gillmor"  wrote:
Proposals for additional cases to test
would also be useful.

=====
PDF renders an empty line as whitespace, even if there is a line
return.

This functionally means that the empty line after the PGP header and
the Cyphertext
will be interpreted as being omitted, even if copied from the PDF.

If it is possible, I would suggest that both cases be accepted, 
i.e.  with a LR/empty line after the header and the cyphertext,
and if no such empty line exists.
vedaal

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 16 Feb 2021 18:52:48 -0500

Hi vedaal--

On Tue 2021-02-16 14:29:19 -0500, [email-masked] wrote:
> Proposals for additional cases to test would also be useful.
>
> =====

I don't know what PDF you're talking about.  Are you referring to a
specific example PDF?  to a (common?) form of translation between ASCII
text streams and PDFs?  to something else?

> and if no such empty line exists.

The goal of the whitespace canonicalization as i understand it is
*exactly* this -- that regardless of how the unprintable characters show
up (or don't), a valid signature will be seen as valid.

However, the thing that is validated is the canonicalized version, not
any of the potential whitespace variants.

      --dkg

---

From: Guillem Jover <[email-masked]>
Date: Fri, 19 Feb 2021 18:08:01 +0100

> they try to follow the spec as written.

Ack.

> https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/11

Thanks. I think there are three related issues here:

  * Non-uniform definition and usage of "whitespace/blank" in the RFC.
    This makes it difficult to understand and interpret what's intended,
    and affects how people implement. (Clarifying this was my main intent.)

  * Consideration on what set of whitespace should be accepted as valid,
    even reducing or augmenting. This is going to create a potential
    tension between interop, backwards compatibility and security
    concerns when chaining various implementations. (I don't mind greatly
    about this one, as for dpkg I'd need to decide based on the least
    common denominator from the implementations supported anyway.)

  * Documenting that regardless of the set of characters defined as
    valid whitespace, accepting a non-reduced set of characters can have
    security implications when chaining various implementations with
    different acceptance checks. (I think this would also be useful
    for glue implementations and "users", such as dpkg.)

> thread?)  -- and if you can also make it as a merge request on gitlab

I might try, but I'm not sure I'll have the immediate time for this.

Thanks,
Guillem