Subject: [openpgp] OpenPGP semantics; questions re DH, SHA-1 with EC privkeys

From: David Leon Gil <[email-masked]>
Date: Tue, 8 Jul 2014 17:03:34 -0400

As there has recently been some interest in new implementations of
OpenPGP (vide sig infra), it occurred to me that a more concise,
slightly more formal definition of the OpenPGP packet syntax might be
useful to implementers.[^nb]

So I dashed up a quick draft, vaguely in the XPEG
(parsing-expression-grammar with semantic-reductions) style,[^xpeg] of
a syntax with non-cryptographic semantic constraints for RFCs 4880
(v4), 5581 (Camellia), and 6637 (EC).

It includes packet headers, packets, algorithms, signature subpackets,
ASCII armor, and cleartext signatures; it does not yet include packet
compositions and the validity constraints on those. (In only 1100
kind-of line-like things!)

I was curious if anyone had anything to add (or noticed any blunders)?

(And has someone else done this that I'm not aware of?)

I'm particularly interested in the following questions, which are
slightly unclear from the RFCs and what I could find on the list:

1. Did X9.42 DH ever see widespread use in any context? (If so, is
there a reference for the ASFs used?) I recall *using* prime-field DH
with an OpenPGP client many years ago, but I believe that it was
especially patched as a test of that functionality.

2. Is it intended for SHA-1 to be permitted for use with the Iterated
and Salted S2K method in RFC 6637 for private key storage? (The plain
text of the RFC does not forbid it, even though it forbids its use as
an ECDH KDF.) It is implicitly forbidden for use as the S2K algorithm
in packet compositions with ECDH and SKESK packets at the 192-bit
security level -- its output is only 180 bits.)

3. Are there any common packet types, signature packet subtypes, or
algorithms that are moderately interoperable (e.g., recognized by most
PGP software or keyservers) but not included in an RFC? (E.g., I think
that GnuPG's(?) keyring format contains some things that other
software recognizes.)

And the following question, which the RFC is clear on:

4. RFC 4880 explicitly states that a user ID and signature are
optional for a public or private key packet composition to be
importable. Most(?) PGP software requires both for prime-based keys.
I'd suggest that requiring a signature is undesirable for ECDH or DH
keys. Are there any implementations that support this at present? Or
should the requirement for user ID and signature packets just be added
as a consensus constraint that hasn't made it to RFC form yet?

(The source for the grammar is under
https://github.com/coruus/openpgp-semantics)

The syntax is attached as a "Markdown" file, but I recommend reading
it in a monospaced font.

- -dlg

[^nb]: This is not to suggest, of course, that there is any substitute
for reading the RFCs.

[^xpeg]: See, e.g., TRX, http://arxiv.org/abs/1105.2576.

---

From: Clint Adams <[email-masked]>
Date: Tue, 8 Jul 2014 21:34:54 +0000

> (v4), 5581 (Camellia), and 6637 (EC).

It would be interesting if this could be used to automatically
validate the types[0] used by hOpenPGP.  Thoughts on that?

[0] http://anonscm.debian.org/gitweb/?p=users/clint/hOpenPGP.git;a=blob;f=Codec/Encryption/OpenPGP/Types.hs

---

From: Jon Callas <[email-masked]>
Date: Tue, 8 Jul 2014 15:33:08 -0700

> especially patched as a test of that functionality.

I'm not aware of anyone actually implementing it. It dates from a dream of being able to cross-code OpenPGP and S/MIME, but I don't think anyone actually ever did it.

> security level -- its output is only 180 bits.)

It's reasonable to use SHA-1 for a symmetric cipher with key less than 160 bits. 

I believe that the last sentence of 3.7.1.3:

   After the hashing is done, the data is unloaded from the hash
   context(s) as with the other S2K algorithms.

describes how you'd do it, as per 3.7.1.1 with multiple hash contexts. The word "context(s)" leads me to this.

If you looked at the GnuPG source code and considered it definitive, that's likely good, as I remember that import of private keys always worked cross-system.

> that GnuPG's(?) keyring format contains some things that other

The "keyring trust packets" which are obliquely described in RFC 1991 interoperate, so far as I know. PGP 2.X used them, and most people kept doing it the same way despite the working group being forbidden to define them and other infrastructure.

> as a consensus constraint that hasn't made it to RFC form yet?

The top-level public key of a "key" must be a key capable of signing. So you can't use a DH key of any type as the top-level key. You can use a DSA or ECDSA or RSA key as a top-level key.

> -dlg

Or in some cases, reading the code.

	Jon

---

From: David Leon Gil <[email-masked]>
Date: Thu, 10 Jul 2014 15:15:45 -0400

Clint: In fact, your work on hOpenPGP was the inspiration for what I'm up
to!

(Details probably not yet interesting to the list-at-large; but yes, think
it's feasible to link up with implementations.)

> It's reasonable to use SHA-1 for a symmetric cipher with key less than 160

Appreciate the confirmation/correction.

(The text prohibiting SHA-1 for the KDF in 6637 is so close to the text
requiring I&S that I wondered whether S2K had been omitted in error...)

The "keyring trust packets" which are obliquely described in RFC 1991
> interoperate, so far as I know. PGP 2.X used them, and most people kept
> doing it the same way despite the working group being forbidden to define
> them and other infrastructure.

Thanks much for the reference. I'll take a look at a few implementations
(I've been trying to avoid specifying GnuPG's behavior rather than
interoperable behavior).

> The top-level public key of a "key" must be a key capable of signing. So
> you can't use a DH key of any type as the top-level key. You can use a DSA
> or ECDSA or RSA key as a top-level key.

You're right. I wasn't taking into account the effect of the
packet-composition rules; those require that V4 primary keys be capable of
certification (and V3 primary keys are always RSA).

And I guess, from the silence on this point, my question is answered: Even
though the RFC states that signatures are optional, even for primary keys,
implementations don't ordinarily import keys without them.

> Or in some cases, reading the code.

Agreed.

-dlg