By stopping short of how the sequence of bytes is stored or
passed, OpenPGP ensures that it is applicable and
interoperable across a wide range of apps ... just by
forcing the developers of the apps to agree on a few local
details.
"just" ???
That argument implies 3 things:
a) it's acceptable to require every implemention to support each other
implementation as a separate special case
b) it's acceptable to require each user to specifiy at the time of
encryption or signing which implementations (not algorithms, or keys,
but implementations!) should be able to parse the result
c) it's acceptable for 2 implementations which support the same set of
algorithms and have the appropriate keys for sharing encrypted or
signed data to say they both have an OpenPGP-conformant application -
but which can't actually share the data.
Am I the only one that thinks this is a flawed argument?
Surely this should be a fundamental purpose for the standard: for you
to be able to encrypt a file using your implementation, send it to me,
and for me to be able to decrypt it with a different standard.
Isn't it??
A spec would not be able to be so conveniently loose ;)
As someone who is trying to write a set of interoperability tests for
my own implementation, I'm not sure I quite understand your use of the
word "convenient" here... :-)
Rachel
P.S. I can take the argument that says a keyring is different, because
it's local to the app. But surely, not encrypted/signed files???