On Fri, 20 Jun 2008 02:37, jon(_at_)callas(_dot_)org said:
I don't see that an OID actually solves the problem. The problem is
that the bureaucracy of IANA needs to assign the bit string. It
doesn't matter if the bit string is an OID or one of our constants.
It solves the problem that one can start using an OID even if it is not
registered with IANA for OpenPGP use. If that OID eventually gets
registered, all works as expected and there is no need to start from
scratch with a new OID or AlgoID. If that OID won't get registered the
existing keys and messages can still be used for testing purposes.
In that sense it is nothing else than our 100--110 range of algorithms
IDs used for testing. However it is more practical.
We can deploy applications and as soon as an OID gets approved for
OpenPGP we can tell users to enable the hidden option xy and everything
works. If another OID get assigned we need to get out a new version.
Compare that to algorithm IDs: We could do the same of course - but what
are we supposed to do if the assumed ID gets assigned to a another curve
and yet another ID get assigned to our curve. That is not easy to
handle and hard to document and explain.
Spending a few extra bytes for an OID is justified - they don't create
noicable larger signatures or keys.
Make one up. Ditto for Camellia. Pick the obvious right number, and we
We do have one for Camellia - however it has changed over the last year
and it is still only desribed in an ID. We can assume that IANA will
eventually assign the suggested algorithm IDs but we can't be sure.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.