3 ms·
The schema is right here: https://under-the-hood.sequoia-pgp.org/packet-structure/ https://under-the-hood.sequoia-pgp.org/packet-structure/ Each bit in the pac
by exabrial 3y ago
The schema is right here: https://under-the-hood.sequoia-pgp.org/packet-structure/ https://under-the-hood.sequoia-pgp.org/packet-structure/
Each bit in the packet is in an RFC actually and well defined. Again, the problem is on the python side.
- woodruffw 3y agoRFC and “well defined” are not the same thing. The RFC process is somewhat well known for producing standards of a wide range in quality.
- exabrial 3y agoLiterally every bit is defined.
- woodruffw 3y agoThat's not something to get hung up on: what matters is the semantics, not whether or not each bit is defined. Here's a good example, in 3.2: > Also note that when an MPI is encrypted, the length refers to the plaintext MPI. It may be ill-formed in its ciphertext. What does this mean? Is the MPI encrypted separately (how?), or something else? Why would you even mention it being "ill-formed" in its ciphertext (it has to be, unless something has gone very wrong), much less use a wiggle phrase like "may"? If you dig further through the spec, you find under 5.5.3 that MPIs can be "secret" MPIs, which are apparently encrypted with a passphrase that gets munged through a KDF defined by an S2K identifier. But this is inexplicable under the "secret packet" part of the spec, not the MPI part. And it does nothing to address the second ambiguity. Here's a place (5.2.3.1) where the spec is unambiguous, but forces clients to be ambiguous: > If a subpacket is encountered that is marked critical but is unknown to the evaluating software, the evaluator SHOULD consider the signature to be in error. This is the exact opposite of what ecosystems like X.509 do; it's a pointless source (perfectly well-specified!) variance on the client side.