Subject: Mandatory numeric examples in crypto-RFCs?

From: [email-masked] (Hadmut Danisch)
Date: Wed, 26 Jul 2006 16:41:15 +0200

Hi,

I am currently debugging some ISAKMP problems and thus using RFCs like 
2085, 2412, etc. about cryptographic algorithms and data formats. 

Such RFCs are sometimes a little bit ambiguous or difficult to read
since details are spread around the paper. When implementing such
algorithms or data parsers, you don't know whether the implementation
is correct without a test case, e.g. feeding in some examples and
check whether the result is what is expected.

I'd therefore propose that every RFC dealing with crypto algorithms or
data formats has to have a mandatory appendix section with examples to
be used as a test case. (Every I-Draft should have.)

E.g. when describing key agreements precise examples of the random
numbers and secrets, byte sequences of example messages, and the
results (signatures, keys,...) should be given allowing to do a simple
check of any implementation to see, whether the implementation works
in principle, and does not have such common bugs like wrong padding,
byte order problems etc.

regards
Hadmut

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "todd glassey" <[email-masked]>
Date: Wed, 26 Jul 2006 08:26:23 -0700

I tried to get this in place several years ago by requesting that the IETF
require specific Use Statements which could be used to accurately reproduce
the technologies in the RFC's or Standards and it wasn't too interested in
that at the time.

The problem is that with the many languages of the submitters it is very
difficult to always tell what is intended - especially when the Editor's try
and fix bad writing - they may in fact alter the alg's without intent. To
prevent this detailed use and protocol transaction flow models are needed.

Todd Glassey

---

From: Russ Housley <[email-masked]>
Date: Fri, 28 Jul 2006 09:10:59 -0400

Hadmut:

Test vectors are very helpful.  We usually include them in 
cryptographic algorithm specifications, as opposed to protocol 
specifications that make use of the cryptographic algorithms.  In 
some cases, an examples document has been written to provide the 
combination of the protocol and the cryptographic algorithms, but 
this usually comes several years later when it is clear which 
examples will provide the most benefit to implementors.

ISAKMP is not likely to have such a document written.  IKEv2 is 
intended to replace ISAKMP in the long run, so there is not much 
interest in further work on ISAKMP.

Russ