On Thu, 2005-08-25 at 06:48, Pekka Savola wrote:
I think there needs to be separation of two different kinds of
documents,
1) informational, because the normative specification is elsewhere
(usually another standards organization) and we could reference the
normative spec directly, and just provide informative reference to the
Info spec).
2) informational document just because, well, the authors thought it
would be easiest to write an informational document. This is the
normative specification, and it may or may not have had sufficient
IETF or security review.
Cryptographic algorithms have been documented via informational RFC's
since at least rfc1320.
Both of your types (standalone and external reference) are present
within the RFC set. For example, the primary specification of MD4 and
MD5 can be found in RFC1320 and RFC1321, while other RFC3174 contains a
specification of SHA-1 and a reference to its primary specification,
FIPS 180-1.
There is no value in requiring documents to have normative references to
FIPS 180-1 instead of to RFC3174.
At least to me, these two categories should be treated differently.
Can you explain why?
Cryptographic algorithms are, in general, hard to use correctly.
Security review of cryptographic protocols involves an assessment of
whether the specific algorithms used actually meet the requirements of
that protocol.
This already puts the burden on the referencing document to ensure the
algorithm is appropriate. Security reviewers can be expected to cry
foul if the only algorithm referenced is an unknown. ("Bass-o-matic?
you must be kidding...").
And security protocols should for the most part be algorithm-agile;
cases where they are not need to be specially justified in the
referencing document.
Exactly *how* the algorithm is referenced from the specification is, by
comparison, a trivial matter. Like the new "all documents must have
IANA considerations sections even if they don't need one" requirement,
this appears to be another exercise in attempting to substitute
mechanized process for judgment.
- Bill
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf