Re: [acvp] ACVP draft comments

"Celi, Christopher T. (Fed)" <> Thu, 28 March 2019 14:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1113F12042D for <>; Thu, 28 Mar 2019 07:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 AWB4d87h1JHo for <>; Thu, 28 Mar 2019 07:44:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E4731202BA for <>; Thu, 28 Mar 2019 07:44:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=scXZ75fcGuYWLjD9AoZpfTyJVrgxHoGjinf1OKJyc6o=; b=cJ60pCS2E+sLohqsBAry6X512Elldghi2VoULD/i69HvTzTr/f8d6R4+NywT8gOwczepSIml023FLV9wKCZiCLhJ8BYtTdMXjHkH115c2FlC7qFTobMd1B+ieCe7dO5tpQ4u9l29VRo8rcP21o6BlKNPnDQDq0Tao7c8SoI418g=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.15; Thu, 28 Mar 2019 14:44:39 +0000
Received: from ([fe80::1dad:f02c:c917:4793]) by ([fe80::1dad:f02c:c917:4793%5]) with mapi id 15.20.1750.014; Thu, 28 Mar 2019 14:44:39 +0000
From: "Celi, Christopher T. (Fed)" <>
To: Yaron Sheffer <>, "" <>
Thread-Topic: [acvp] ACVP draft comments
Thread-Index: AQHU5U+SiFYjylJ9JEq68kvj4u47g6YhHq3K
Date: Thu, 28 Mar 2019 14:44:39 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2610:20:6005:218::3]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6b0dca10-7d84-4cc1-b0ad-08d6b38be7f0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:BL0SPR01MB0028;
x-ms-traffictypediagnostic: BL0SPR01MB0028:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 0990C54589
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39850400004)(396003)(346002)(136003)(376002)(189003)(199004)(55016002)(54896002)(7696005)(186003)(53936002)(6306002)(9686003)(316002)(74316002)(236005)(33656002)(7736002)(19627405001)(106356001)(105586002)(2906002)(6246003)(102836004)(71190400001)(6116002)(68736007)(97736004)(71200400001)(606006)(6436002)(14454004)(46003)(52536014)(229853002)(6506007)(53546011)(86362001)(5660300002)(478600001)(446003)(11346002)(476003)(486006)(25786009)(8936002)(256004)(14444005)(110136005)(2501003)(6606003)(81156014)(81166006)(76176011)(99286004)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0SPR01MB0028;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: JYjJ7dxGlGU6DIf/1oqZxvzG1Q/am6qv0DogCGn7ET9ZMCn661I65jLX0/HF3iefV9uJUE1UBdYVtXkjDH86asPYk4/0Cfd3jotMFjDDAW6JGnQgnIe5/1CU6JpUYVg/a8S9TJF4wlY2BZo3nYcF8SvveIS85xKddvnk97LrEFo+9n7DnvaAa59RLELa1KWie/70V38yvh3BCu0S8I2SDbHNc4Fjol/Mb+d7lc/R/md38X7289pR0oZFtlefXGeUbHMNLejKeeG+rH1iVRl/P1+doBUfZcfZY6/NOr46p/W0fj8mm+MKtFuzUWUxhYBJBLHLK+/wwIHstdjRgRNciWljkr4r8jUiou6Y+iBgXW/XFMC5JofmvutgvT5F8clTZm9baCuOISTpTpH9TXPTVQWlrECYOX+CQTJ8vP7cnAo=
Content-Type: multipart/alternative; boundary="_000_BL0PR0901MB36971533A189FB87BE54BD45F0590BL0PR0901MB3697_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6b0dca10-7d84-4cc1-b0ad-08d6b38be7f0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2019 14:44:39.0989 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0SPR01MB0028
Archived-At: <>
Subject: Re: [acvp] ACVP draft comments
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, 28 Mar 2019 14:44:46 -0000


In the symmetric block cipher draft, there is negative testing for GCM (and GCM-SIV) decryption operations.

Thank you for the feedback.

Chris Celi

From: acvp <> on behalf of Yaron Sheffer <>
Sent: Thursday, March 28, 2019 6:17:39 AM
Subject: [acvp] ACVP draft comments


I reviewed the spec in some depth, but only skimmed the other major document. So here are a few comments. Thank you for this important work!


* FCS: expand the acronym: in the Terminology section?

* Why support HTTP (as opposed to HTTPS) at all? IMO TLS should be REQUIRED, not RECOMMENDED.
* What is the difference between validation testing and crypto assessment testing?
* The notion of "verifiable artifacts" is not well defined here or possibly even bogus (any crypto module can be subverted to produce fake results), so I wouldn't use it.
* Authentication should actually be in scope, at least to enable a minimum interoperable implementation.
* "Mutual authentication", you probably mean TLS with mutual certificate-based auth, please clarify.
* DRBG: expand.
* Figure 1: I would think the DUT is only the crypto module, and does not include the ACV client which is not actually being tested.
* 4.1: please clarify the notion of real-time vs. non-real time operation. It's not clear to me where real-time testing can be useful. (This is explained later, so maybe add a forward reference to the Terminology).
* I am sure you're already used to it, but first-timers will be highly confused by the sense of request+response which is opposite the usual: server to client. Can we rename them?
* 5.1, please use an URI (RFC 6761).
* 5.1, version numbers are later included in the URI, but not here. Why?
* 6.1, as noted above, IMO a single baseline authentication method should be mandated, though implementations may choose to add others.
* 7: the word "extensions" should be quoted. Better yet, give an example. It is also very common to have an IANA registry for extensions names, in order to avoid conflicts, and/or to give a naming convention such as using a DNS name of the organization (similar to Java packages).
* 8: this is not well-specified. What if a new port is NOT required? Also, what is the syntax for the secondary port? How is it authenticated? And in fact, why is it ever needed, i.e. why would a server agree to accept on an auxiliary port what it refuses to accept on the main port?
* 9. This section mentions "major/minor" but the examples all have "v1". In general this section needs a lot more clarity.
* 10. Maybe start the section with a quick overview of the message exchanges.
* 10.1. Primary contact? I'm not sure it is useful to configure people's names on the servers.
* 10.2. It is implied that you cannot have multiple outstanding requests in parallel for the same client. I suggest to make it explicit.
* 10.3. Alg:none should never be used in production, and also, never in a standard.
* 10.3. "Key agreement would follow RFC7518." I'm not sure what you mean. I suspect you want to say, Keys are pre-provisioned to the client and server according to RFC 7518.
* 10.3. More work is needed on the JWT: you want integrity protection, not encryption. Unless you're passing the database key, in which case you do need encryption. HS256 is obviously only integrity protection. Also, you'd want a public key (RS256) rather than a shared HMAC key, for better security.
* 10.3.2. Why use the expired token in the exchange? This means the server should have a special case where it accepts expired tokens - not very good.
* 10.5. Please avoid Markdown "bold", it doesn't render correctly in the text version.
* 10.5. We should discuss the use of JSON Schema (<>) to avoid lengthy an ill-defined examples.
* Are you sure you want the complexity of PUT, with per-property updates? This breaks once you have arrays. For example, you cannot add or remove a single phone numbers, you have to specify them all.
* Having the DELETE methods as "optional" makes it very hard to test this API. I would suggest to have them as mandatory, but *allow* servers to refuse them based on policy (and then return an error code).
* 10.8.3. Dependency properties seem to introduce too much complexity. I would assume they can be hardcoded or maybe specified here, but not available for listing/parsing at run-time.
* Algorithms: in many cases you have a cross-product of name X key-length X mode. Maybe for these cases you want an array of available key-lengths and an array of available modes, provided all combinations are supported.
* What does "encrypt at rest" mean, and why is it a parameter at all?
* When listing sessions, I would expect a status field: not-started, in-progress, complete-passed, complete-failed.
* Why is there a per-session access token, why not reuse the on-going login based access token?
* "Expiry" field, please use standard ISO8601 time, as usual. Besides, the current format lacks a time zone.
* 13. Returned errors: please use RFC 7807 rather than creating a new format.
* IANA section: better incorporate it into the main document.
* draft-celi-block-ciph: is there any support for negative testing, specifically cases where AES-GCM decryption should fail because the auth tag is incorrect?