At 8:50 AM -0800 2/12/10, David Conrad wrote:
On Feb 12, 2010, at 7:57 AM, Stephen Kent wrote:
Who gets to decide on what algorithms get first class status and
based on what criteria?
If we look at what the CP developed in the SIDR WG for the RPKI
says, the answer is the IESG
So, they're going to flip a coin or what?
"Who" is largely irrelevant. The criteria is the interesting bit.
Both issues are relevant. Most of the other WGs dealing with this
issue have been in the secruity area and feel comfortable making
these decisions. The IESG has been comfortable with their decisions.
Note that change have been made, for other than technical reasons,
e.g., initially TLS had DH 7 DSA as MUST and RSA as SHOULD, because
of patent issues. When the RSA patent expired, the roles were
reversed. So the IESG has been an active participant in these
decisions in the past.
>> Steve brought up "national" algorithm, but we have also
"personal" algorithms such as curve25519 or threefish.
WGs like IPsec, TLS, and SMIME have been able to say no to
"personal" algs for a long time.
IPsec, TLS, and SMIME are all one-to-one. DNSSEC (in this context)
is one-to-many.
Your observation is applicable to IPsec, not to S/MIME, and, for
practical purposes, not for TLS. An S/MIME message may be sent to
multiple recipients, so it is not literally one-to-one. S/MIME
accommodates algorithm diversity best for the public key algorithms
used to encrypt the content encryption key. It also can accommodate
diversity for the algorithm used to sign the message, but at a higher
cost. It does poorly if different recipients make use of different
content encryption algorithms. TLS is nominally 1-1, but in reality,
the vast majority of TLS use is for access to web sites that have a
very diverse set of clients. That requires a small set of mandatory
algorithms, to ensure interoperability. Finally, the question posed
was about how have decisions on which algorithms are mandatory to
implement have been decided in the IETF in the past. My reply
addressed that question.
Regards,
-drc
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf