Phillip Hallam-Baker wrote:
The illusion of control is comforting to some but it is an illusion. At the
end of the day the IETF has roughly 2000 people involved. Nobody elected us.
We are accountable to no-one.
I assume the number of IETF contributors is more like 5000-10000.
The Internet has 2 billion users. We do not accept accountability to those
users. We cannot even understand what their requirements might be. And even
if we did, we may well reject them out of hand.
Everybody can get involved with the IETF and although some working groups
may have superseded rough consensus by voting these days, there are still
significant numbers of contributors involved in the IETF with non-marginal
levels of dignity about the technologies they are creating.
The first cost is the cost of maintaining the registry. Assigning code
points requires an administrator, it frequently requires expert review.
That incurs time and money.
You are asserting here that by _not_ using an IANA registry, but instead
relying on ASN.1 OIDs, suddenly the use of DSA with MD4 for a digital
signature obiviates expert review and becomes technically sound?
The assignment of a code point itself is a cost infinitesimal close to
zero. No matter how you look at it, at the abstract level there is
no difference between an IANA code point assignment for something
and the assignment of an ASN.1 OID or an URIs by some organization.
But building and implementing protocols with small fixed-size integer
IANA-assiged values is magnitudes easier than messing around with
ASN.1 OIDs and URIs in terms of code, CPU cycles, storage requirements
and network bandwidth. But the IANA assignment has the clear advantage
that it is a well-known single location that keeps track of all
assignments and associated specifications, while with ASN.1 OIDs
and URIs you might find yourself lost where no google/bing/whatever
heuristics can help you.
I know of a colleague who is struggling trying to move an RSA keypair
created on an IPhone to a Windows machine, but the default RSA CSP in
MS CryptoAPI rejects the keypair on PKCS#12 input (Firefox and OpenSSL
don't have a problem). I'm suspecting it might be due to a primality test
suggested by X9.31, but that document is available at $$$ only.
With an IANA registry, the IETF can (and should) enforce free availability
of the relevant specifications plus at least availability of RAND conditions
for the surrounding (known) IPR claims.
The second cost is that where there is control, the granting of a code point
will inescapably imply approval. I have no problems with the Russian
government using GOST but I do have serious problems with the fact that the
IETF has assigned code points for GOST.
I have no problem whatsoever with _code_points_ being assigned for GOST
by the IETF as long as there is a specification that describes the
exact semantics for the specific protocol context where this assignment
applies.
Attributing a recommendation level to the _use_ of GOST algorithms
for specific purposes is an entirely different matter.
There are code points assigned for cryptographic algorithms
like RC4-40 and MD4 for use with IETF protocols. I'm much more
concerned about those than I am concerned about GOST.
Frankly, I'm actually more concerned about code assignments for
severely IPR-impaired algorithms (e.g. Elliptic Curve related)
than about GOST. (Admittedly, the GOST 34.10-2001 signature
algorithm appears to use Elliptic curve math, and it's entirely
unclear to me whether and how existing EC-related IPR claims might
apply.)
(yes, yes, TLS suites, blah, its fixable)
The most appreciable part of TLS is, that it did not add any new
ASN.1 nonsense to the existing mess of X.509/PKIX.
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf