[saag] Re: New Version Notification for draft-rsalz-crypto-registries-00.txt

[Tero Kivinen <[e-mail]>]

Simon Josefsson writes:
> Good.  I don't claim the document encourage rejecting non-NIST crypto,
> but I think the document may be a useful tool for people who want to
> delay deployment of strong non-sanctioned crypto.  The document suggests
> "Specification Required" for all registries.  This is a limitation
> compared to broad set of different policies allowed by RFC 8126.

I definately want the minimum bar to be "specification required".

Almost only case where someone does not want to provide public
specification for an algorithm is when it is supposed to be national
secret crypto to be added, but I think they can use private use values
for those. 

If there is no specification available publicly then how are people
going to implement an algorithm?

Note, that even if the registry is expert review, experts quite often
do require that specifications to be avaiable, i.e., about same as
specification required.

> Limiting the registration policies is one method to make it harder
> for people to interoperate protocols with non-blessed crypto. In my
> perception, this aspect was used to delay publication of 25519 and
> currently ssh-ntruprime.

How was the publication delayed? Publication != RFC, there is lots of
ways to create specifications that are public available. 

> While good arguments may exist for "Specification Required" in some
> protocols, I don't follow why this is necessarily the right thing
> for all protocols. The First-Come-First-Serve policy for SASL
> mechanisms have worked fine, and allow experimentation with
> non-blessed crypto if people care to do so.

For the SSH there is already first come first serve policy (all names
that contained @) but for some reason that was not enough. And
implementations and interoperability works fine even with those first
come first served names. There is no reason to require strings without
@-chracter for algorithms, both forms work fine in the
implementations.
-- 
[e-mail]