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

"Vassilev, Apostol (Fed)" <apostol.vassilev@nist.gov> Thu, 13 September 2018 19:56 UTC

Return-Path: <apostol.vassilev@nist.gov>
X-Original-To: acvp@ietfa.amsl.com
Delivered-To: acvp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23AA12426A for <acvp@ietfa.amsl.com>; Thu, 13 Sep 2018 12:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsiLZrMnvQkm for <acvp@ietfa.amsl.com>; Thu, 13 Sep 2018 12:56:05 -0700 (PDT)
Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0128.outbound.protection.outlook.com [23.103.201.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A5A126CB6 for <acvp@ietf.org>; Thu, 13 Sep 2018 12:56:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mcFAjZqs49fkgJkHYjawMf2ztVBfutV2SI2xsupaChE=; b=tp3QNeAB62LAVt7TwTYzdOLoOsxGcLYdKYj7gZysFwbFVtz3BaLPq4SmXlfXrAj3lgIMbQkTN72iWaz3qLX1uzlPHQhzmiNzSHlSiF9s4HgcvEy/uJGTIfK6oGhCw3x1Xi0sB7rxgpejYvzuwy8WAkKeIvvMe1MrDiu+QfqNOTY=
Received: from BN3PR09MB0625.namprd09.prod.outlook.com (10.160.120.140) by BN3PR09MB0626.namprd09.prod.outlook.com (10.160.120.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1101.15; Thu, 13 Sep 2018 19:55:51 +0000
Received: from BN3PR09MB0625.namprd09.prod.outlook.com ([fe80::38fb:a217:4433:86b5]) by BN3PR09MB0625.namprd09.prod.outlook.com ([fe80::38fb:a217:4433:86b5%7]) with mapi id 15.20.1101.020; Thu, 13 Sep 2018 19:55:51 +0000
From: "Vassilev, Apostol (Fed)" <apostol.vassilev@nist.gov>
To: "Barry Fussell (bfussell)" <bfussell@cisco.com>
CC: "algotest@list.nist.gov" <algotest@list.nist.gov>, "acvp@ietf.org" <acvp@ietf.org>
Thread-Topic: A strategy for IETF-ing our specs
Thread-Index: AQHURunNvpva9pL9n0KA9dfOnZL+/aTuqSaAgAAAj4A=
Date: Thu, 13 Sep 2018 19:55:51 +0000
Message-ID: <2EF224DE-AE52-41CC-BF42-9E7C49B4702D@nist.gov>
References: <EB980FD2-27D0-4900-AAFE-E825F5B9F458@nist.gov> <d4e81ab779bf4736aba8372da74ba6a6@XCH-ALN-004.cisco.com>
In-Reply-To: <d4e81ab779bf4736aba8372da74ba6a6@XCH-ALN-004.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.9.1)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=apostol.vassilev@nist.gov;
x-originating-ip: [132.163.222.170]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR09MB0626; 6:Teq63Bxgx72LsiqYadSlhUJxJuBIohRg3bWRQ52M6r4id+i6bo6RVbCuqxzP21ywJQk4zuCY2OZBTA4/XSrD/+QgH/X8rHM0wG3ISpOy/CsnYfhn1eba1OEb41FpbJygD3CM32+EM5SAptqhqWyI9kQB1vNIMLuvlWvnAUjZ+MfjkoaM1u/EHuRdsw3dD0/ku5cqu0fnMWwwZzMqmsJHMep59LplEkXrEz3OU1cTk1XW+4kEffUJuTwbjXFBHLcFCJyuW6awD87CekZCTdazuVJZM31yI9kttC1GTmtzz27wmdt4JYrhG8J/zOvTIMq31oIaIW0U2tuREbrwlzPEOiu7/oo3UJkgQOV0R95lKlTY0pqhd9LNoVZQVmCWEdW22YoxxJyAVlAivxnA/6FizpYqijbNg/3f+WESfhQb9JfhlCFGAH2KtKwXYCMniWevSQY1VX0Xx6hoK0oBYYY2KA==; 5:LglKjz1GfjaVG1mVpgCcsHbH6mgGifghod96CaxJwe3aD580hTThZBpIE1sZyCK6yzOcJjeTWzsaPA7QmwhQlPepZNS0KeEJK6Deg+T4BMcnlOaWDcC16qqIxq18fEVdyP9wwMsx0eRhOijilcOzzEXImi+Qz+0MmCUSogr/l0s=; 7:EL2rZ84BPZ0mcHSLkuPqECEYrirg2/FA63yFtR+HgBSSeqdUpfTSGVxxU5m/zcLFt0Olh9GsYKTrB0rbE5azV8yOKaSd9vZLwDX5dEK/BnCxmJ007X0Per3YWFt4kKViqd9wRKXZMoWSsI9oox724hFbz1GmX5ycDKplczFfuWGTAB1ImG5zgNOwP9acB1obzrGy1zhaPCzP6xmalY6XYXE6tnScP362swRkjkKjt37mwLYinsJXbkx0+gl5UWIk
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 2ae18c3f-1c19-4f99-df5c-08d619b2e875
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BN3PR09MB0626;
x-ms-traffictypediagnostic: BN3PR09MB0626:
x-microsoft-antispam-prvs: <BN3PR09MB0626FBAF13FC55968E94143CFF1A0@BN3PR09MB0626.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(65766998875637)(166708455590820)(228788266533470)(211936372134217)(95692535739014);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(823301075)(93006095)(93001095)(10201501046)(3002001)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201708071742011)(7699050); SRVR:BN3PR09MB0626; BCL:0; PCL:0; RULEID:; SRVR:BN3PR09MB0626;
x-forefront-prvs: 07943272E1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(366004)(136003)(39860400002)(13464003)(189003)(199004)(5250100002)(14454004)(57306001)(478600001)(6916009)(97736004)(99286004)(68736007)(76176011)(50226002)(53936002)(106356001)(6486002)(966005)(6306002)(6436002)(33656002)(6512007)(86362001)(8936002)(6246003)(105586002)(2900100001)(229853002)(8676002)(25786009)(4326008)(36756003)(256004)(81156014)(446003)(54906003)(5660300001)(305945005)(7736002)(82746002)(316002)(2906002)(6506007)(53546011)(186003)(102836004)(83716003)(486006)(11346002)(26005)(81166006)(2616005)(66066001)(3846002)(476003)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR09MB0626; H:BN3PR09MB0625.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
x-microsoft-antispam-message-info: psVh0gZ31WHQiUD8o8RSo1MDeRQo2O2lPrtPoUx8FuD2NwIAGMYuqwvIKpVWP1yetBgtgwZrIqcygTRNvUkuCbaACbLbxSarW3xYVkgQZpaENr43TjYxkY7Yrxtx/oRA5zjw8tB7t6vDrb6vtKYshVIKDbmTI9KfsSFt/WDxNWpLavXyTDOIeriioB6fp5nidzRuct/vX5J1EgAsWc3kyocZ0mepIX0SOOfqFfU8aXhdO4C5tHI8fV3WmuTaWqrdE1J+PXMzsG/Ka5FAc9jq3PeQdH+got2aDE9gQ/o6IqjyIMj3VlZoDYZZr/00XNJzzyX8GhDY+50ykyKuvXBuwScvmvkY3JrbI/hwoZBW04g=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EFAB68DEF267CD4581685DEC81DA528B@namprd09.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: 2ae18c3f-1c19-4f99-df5c-08d619b2e875
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2018 19:55:51.2114 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR09MB0626
Archived-At: <https://mailarchive.ietf.org/arch/msg/acvp/swTLeVQ8Gp2gEBfJDK8DhMq4Hhk>
Subject: Re: [acvp] A strategy for IETF-ing our specs
X-BeenThere: acvp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Cryptographic Validation Protocol <acvp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acvp>, <mailto:acvp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acvp/>
List-Post: <mailto:acvp@ietf.org>
List-Help: <mailto:acvp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acvp>, <mailto:acvp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2018 19:56:08 -0000

Thanks, Barry. Stay safe from Florence. 

Regards,
Apostol


> On Sep 13, 2018, at 2:53 PM, Barry Fussell (bfussell) <bfussell@cisco.com> wrote:
> 
> I'm on board with this, will include IANA Considerations section in the protocol spec.
> 
> -----Original Message-----
> From: Vassilev, Apostol (Fed) [mailto:apostol.vassilev@nist.gov] 
> Sent: Friday, September 07, 2018 4:32 PM
> To: algotest@list.nist.gov; acvp@ietf.org
> 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 https://github.com/usnistgov/ACVP) 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.     
> 
> Thanks, 
> Apostol
> 
> -- 
> 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 algotest+unsubscribe@list.nist.gov.
> Visit this group at https://groups.google.com/a/list.nist.gov/group/algotest/.