At 10:57 -0500 2/12/10, Stephen Kent wrote:
If we look at what the CP developed in the SIDR WG for the RPKI says, the
answer is the IESG (going forward, after an initial set of algs are adopted
based on the SIDR WG process). In the IPSEC, TLS, and SMIME contexts, the WGs
themselves have made the decisions, which the IESG then approves by virtue of
the usual standards track RFC approval process. I do not believe that the
criteria have been documented uniformly across these WGs.
What is "CP?"
At 15:11 -0500 2/11/10, Olafur Gudmundsson wrote:
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.
I've asked this before (see
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg03057.html):
what is a "national algorithm?" I asked that in the DNSEXT WG and
didn't get a response. There's a definition in
http://www.ietf.org/mail-archive/web/secdir/current/msg01343.html but
from that I can't distinguish between Skipjack (in that it is labeled
as national) and DES (not-national but "published by [US] NIST as
FIPS").
But in the bigger picture, for different reasons, I think the
"SHOULD" in question be removed/changed. I think it is up to an
implementor to choose whether they implement something or not,
support RFC wxyz or not. And it is up to the RFP write to require it
or not. I don't think any RFC can "MUST" itself into existence.
PS - I think Olafur meant "private algorithms" not personal
algorithms. See
http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml,
registrations for 253 and 254.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf