[openpgp] v5 in the crypto-refresh draft

[Daniel Kahn Gillmor <[e-mail]>]

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

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

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. 

 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 name),
      - 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
-------------------

(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?
    
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.

-----

(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).

-----

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

----

(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
----------

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