-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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.
-----BEGIN PGP SIGNATURE-----
Version: End-To-End v0.3.1338
wv8AAABmBAETCAAY/wAAAAWCU7xcif8AAAAJkADAmcXA0CgpAABO2gEAhBTDGf8Y
30WFKX3tCWbT9Vq/rKNN9X2HT6YlJkSIF9kA/AydkuTiP6MJHXUUPdcU8pNTSWI1
Afyc9NrxCQVs17Da
=BxME
-----END PGP SIGNATURE-----
openpgp-syntax.markdown
Description: Binary data
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp