Personally I find Tom's input to this working group very useful, as
his input is based on actually trying to implement an OpenPGP
implementation from the spec.
Tom writes:
Algorithm numbers are assigned so that IF two people decide to use
THAT particular algorithm, they have a common ID for it and a spec
they can follow to interoperate.
Well we have common IDs, but no specs for what a lot of the IDs point to.
No Detail. So there are lots of different and non interoperable ways
of implementing what already is there. And that is my point.
You appear to be saying that there are algorithms which are
incompletely defined.
I think we should distinguish between "ID reserved" and an algorithm
which is intended to be fully defined.
It seems reasonable to reserve an algorithm ID, even absent parameter
details (block mode, etc.,) as long as this ID is clearly marked as
reserved. (I interpret this as "ID Reserved, don't implement yet".)
If there are algorithms which are intended to be defined, but are
incompletely defined (and Tom would know more than most about this
area having tried to implement as much as possible from the spec) then
they either need to be relegated to "ID reserved", or to have the gaps
filled in quickly!
Perhaps if we could clarify the intended development path for reserved
IDs, this area could be made more clear.
For example that they will be defined in a separate RFC? or that they
will be defined in future revisions of OpenPGP? And some comment
accompanying them: that you should not implement them in the mean
time, or that it would be reasonable to discuss how to implement them
on list rather than rushing off and implementing and deploying some
random and possibly not-so-good selection of parameters.
I thought the spec (for this revision) was in final call and isn't being
written any further and editing is limited to only the most severe
problems. You want to add incomplete definitions of new algorithms to the
existing incomplete definitions and submit the spec in this incomplete
state?
An incomplete definition of an algorithm is a servere problem! (And
that includes MAY algorithms.)
I have been pointing these problems out for months. Well it is now final
call, so there is no time for me to repeat my questions about what is
missing (or do I hear a suggestion that we don't submit the draft for
another two months). No one defined these things, nor have I seen any
messages filling any gaps in the specifications.
I think that the set of algorithms which go forward in as the final
document should be fully defined. This could happen by filling such
gaps quickly now, and maybe by removing some algorithms, or by
demoting those algorithms which are not fully defined to be IDs
reserved for future use if necessary for timeliness.
Would you like to kick off with a list of still outstanding problems?
Adam
--
print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`