Re: [acvp] A strategy for IETF-ing our specs

"Barry Fussell (bfussell)" <> Thu, 13 September 2018 19:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE3F6130DCA for <>; Thu, 13 Sep 2018 12:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SzQU2WqV0YXM for <>; Thu, 13 Sep 2018 12:53:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C3D8126CB6 for <>; Thu, 13 Sep 2018 12:53:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4854; q=dns/txt; s=iport; t=1536868431; x=1538078031; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=YcGC92xHbk9bNYu25G3rQOSZ/6t8R3sYZUiVNbHGW44=; b=K6acedsCOA3nJJukTHgg4wc5f4Oq+Ng9iTltxXPqc+QE+w3Xlpe+Pv6W 1qIXacFhWEjhZQoBrSyOhFFbrC2yn01ll9L0zPsIRQGHSc/rTxWIxXN9U QKwIVR9oJRZgKCKYGJfN3FIYbAKoD+Cil3uKLdKG/b6suK6xp5Pyz/XMY w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.53,370,1531785600"; d="scan'208";a="455147456"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2018 19:53:50 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w8DJrom6012420 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Sep 2018 19:53:50 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 13 Sep 2018 14:53:49 -0500
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Thu, 13 Sep 2018 14:53:49 -0500
From: "Barry Fussell (bfussell)" <>
To: "Vassilev, Apostol (Fed)" <>, "" <>, "" <>
Thread-Topic: A strategy for IETF-ing our specs
Thread-Index: AQHURunNaXc/yZbw1E6crpUQzqjPOqTuqODg
Date: Thu, 13 Sep 2018 19:53:49 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [acvp] A strategy for IETF-ing our specs
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Cryptographic Validation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Sep 2018 19:53:54 -0000

I'm on board with this, will include IANA Considerations section in the protocol spec.

-----Original Message-----
From: Vassilev, Apostol (Fed) [] 
Sent: Friday, September 07, 2018 4:32 PM
Subject: [algotest] A strategy for IETF-ing our specs

I have been thinking about a strategy for positioning the ACVP and the algorithm test specifications within IETF.

One of the objectives for going to the IETF is that we want to have standard mechanisms for automated testing of cryptographic algorithm implementations. 

However, at this stage, there is nothing that binds the ACVP protocol specified in draft-fussell-acvp-spec-00 (see to the algorithm test specifications, e.g., draft-celi-block-ciph-00 or to the extension document draft-vassilev-acvp-ext-00. They are related to each other only because they are collocated in the same repository. This is not satisfactory for achieving the stated  objective.

To bind them properly we should think about each algorithm test specification, currently available and new to be developed in the future, as extensions to the ACVP protocol. There will be a new IANA registry for the supported algorithm extensions. For example, this registry would contain a table that links the taxonomy of algorithms listed in draft-vassilev-acvp-ext-00 to each algorithm test specification, e.g. draft-celi-block-ciph-00. Then the protocol spec, in section IANA Considerations, would list the specific IANA registrations for the algorithm test specifications that it currently supports. In addition, IANA offers protocols for managing registrations which would provide us with a robust mechanism for managing the ACVP extensions as we add algorithms beyond those approved by NIST.    

I recommend checking RFC 8126 for information on IANA registries.   

This means that we would need to rework the three initial specifications first, the rest of the algorithm test specifications later, along these lines. It seems to me that we may have to break up the block cipher spec into individual specs for each individual algorithm/mode, which would have its own IANA registration. It may also mean that each algorithm spec may have to elaborate on the basic flows for registration and testing with ACVP. Currently, these flows are kind of explained in the ACVP spec and the individual algorithm test specification only list a ton of properties one can use with these flows. This is not very transparent for the reader and may lead to confusion. Instead, each algorithm test spec should contain an explanation of the basic flows for ACVP: registration, requesting test data, submitting test results, etc, with specific examples. Right now, there are only examples in the appendices but there are no sections explaining them. 

Moreover, the extension specification in draft-vassilev-acvp-ext-00 would become the specification of the IANA registry for ACVP extensions. 

Lastly, the protocol spec in draft-fussell-acvp-spec-00 would reference the IANA extensions it supports in its section IANA Considerations.   

Please give it some thought and provide feedback.     


You received this message because you are subscribed to the Google Groups "algotest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
Visit this group at