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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf