-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Apr 15, 2008, at 5:25 AM, Ian G wrote:
A high level / managerial perspective. Apologies in advance for
where it drifts from actual specifications.
We are deep down the rabbit hole known as
_profiles v. algorithms_
It is worth standing back and thinking about this because when V5
keys are looked it, it is possible that we could solve this.
PGP was designed in the early 90s when algorithms were thought to be
all there was to crypto. Now, we know that's wrong [1]. Now, we
know it is all about applications and users, and they want
communication before security, and security before crypto. From a
crypto standpoint, profiles are the only way forward, because they
remove interoperability issues, which improves communications.
But, still, today, OpenPGP prefers to indicate algorithms not
profiles, so what to do?
From here, nothing. This is layering. At the bottom layer, there's
the algorithms, as you note. A layer up from that you get profiles.
The profiles can either be implicit in the implementation, or they can
be explicit in some standard.
I would actually say that there's the raw algorithm (like AES), the
extended algorithm (like CFB), and the protocol (like OpenPGP). Above
that, as you note are the profiles. This isn't even a Kerchoff issue,
it's a systems engineering and design issue. If you don't give the
implementers liberty, they can't do cool things no one else thought
of. If you give them too much liberty, they write crap. Between those
two problems is wisdom.
I have no personal interest in making profile documents. I support
other people who have such interest. The profiles do exist, however.
They're just implicit in the application.
I think it's better for ECC/SuiteB to have them implicit. But if
someone else wants to do the work, sure.
Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII
wj8DBQFIBRlQsTedWZOD3gYRAlLSAKDReEI/NMupzw2Vqgih93rK2oqppACgyX0b
tG/kRNUqBsJPRVClIJ1idA4=
=6cLL
-----END PGP SIGNATURE-----