From 773759fd789865683b28bf04aa9025b9510af70e Mon Sep 17 00:00:00 2001 From: David Benjamin Date: Tue, 25 Jul 2023 16:21:22 -0700 Subject: [PATCH] Add some guidelines on completeness. This is partially covered by a couple bullet points under precision, but I think it's worth calling out explicitly, and expanding on it a bit. --- draft-irtf-cfrg-cryptography-specification.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/draft-irtf-cfrg-cryptography-specification.md b/draft-irtf-cfrg-cryptography-specification.md index 935bc16..1c3c39e 100644 --- a/draft-irtf-cfrg-cryptography-specification.md +++ b/draft-irtf-cfrg-cryptography-specification.md @@ -397,6 +397,24 @@ abstractions help make the job of using the object in higher-level algorithms easier and less prone to code duplication. +### Completeness + +The operations defined in a cryptography specification should be complete, with +defined behavior on all inputs. This includes error handing, and edge cases +which would otherwise not impact the algorithm's cryptographic properties. +In particular, when deserializing a byte string, the behavior on all byte +strings should be defined, including cases which would not be valid outputs of +the corresponding serialization function. A complete specification help avoids +implementation variations. These variations can lead to interoperability +failures, gaps between formal analysis and real-world practice, or security +vulnerabilities. + +Avoid defining multiple implementation behaviors as valid. Leaving multiple +options to implementators leads to compounding complexity: downstream +specifications may need to profile the algorithm to pick the preferred option, +and validation tools must be configurable to assert either case. + + ### Documentation and Examples Thorough documentation and illustrative examples play a crucial role in