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.
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.
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.)
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.
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.)
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.
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 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.
(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.
Or in some cases, reading the code.
Jon
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp