Daniel Kahn Gillmor <dkg(_at_)fifthhorseman(_dot_)net> writes:
To raise the profile of this specific issue and facilitate testing, i've
extracted the artifacts for the relevant tests into their own repository
A couple of issues with this...
* The 4+23 signature is reported by pgpdump as being another 4+4, not a 4+23,
so either pgpdump is getting confused or it's not actually a 4+23.
* The version number in the tests should really be 5 or at most 6, not 23.
When performing version checks my code allows future versions one or two ahead
of the current one, but a jump of nineteen versions implies corrupted data,
not a time-warp leap of around 200 years worth of standardisation (currently
about ten years per rev). So I'd say code is quite justified in rejecting
what looks like a gibberish version number.
* The test vectors should include a file with just a single version n+1
(currently 5) signature to see what happens when there are no sigs present
that can be processed.
* Because of the way OpenPGP formats messages, it's unclear what an
implementation should do when it hits a version it can't process because
there's no way to tell whether any more data that it can process will appear
later. Consider a streaming implementation that sees a header, the payload,
and a signature with a version it can't process. Because of OpenPGP's
concatenation-of-packets format rather than encapsulation format it can't tell
whether there's more signatures to follow that it can process, so what should
it do with the one signature it's seen? And if the answer is "buffer it in
the hope that more signatures will turn up", how many should it buffer while
waiting for one it can process? 10? 20? 100? 1000? Or should it report
the first signature as a signature-failed and hope more turn up? I'm not
actually sure what my code should do in this situation, so perhaps the new
spec could make some comments on how to handle this.
And based on all this a followup question:
* How badly do we really need a new incompatible-format signature?
Peter.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp