Protocol Workstream#
The Protocol Workstream defines the interactions between the automated CMVP server and the ACMVP clients supporting a proof-of-concept of automation capabilities. The CMVP hosts a demonstration server for interoperability and testing purposes through NIST. This is referred to as the ACMVP Demo Server. The ACMVP Demo Server supports testing labs to connect the outputs of their testing results with the CMVP with minimal human intervention, enabling streamlined submissions with less potential for delay. and to support testing labs to connect the outputs of their testing results with the CMVP with minimal human intervention.
Protocol Workstream Collaborators#
The ACMVP Protocol Workstream is led by Barry Fussell and Andrew Karcher of Cisco and Christopher Celi of NIST, with contributions from Panos Kampanakis of Amazon, Michael McCarl and Deborah Harrington of AEGISOLVE, Alex Thurston of Lightship, Stephan Mueller and Walker Riley of atsec information security, Mike Grimm of Microsoft, Chih-Kao Liao of Intertek, Robert Staples of NIST, and Raoul Gabiam, Michael Dimond, Kyle Vitale, Doris Rui, and Matthew Fortes of the MITRE Corporation.
Technical Details#
Intro#
The Automated Module Validation Protocol (AMVP) defines a mechanism to submit registration, test evidence and validation requests for a software, firmware and hardware crypto modules. It works in conjunction with ACVTS and ESVTS to improve the speed of validations at a rate which meets typical industry development cycles; providing the ability to deploy validated crypto with CVE fixes much faster than previous methods.
The AMVP specification describes how the protocol is structured with respect to the client-server model, messaging, optional features, and flows. It defines how the registrar and evidence submission client communicates with an AMVP server; including module capabilities, session management, authentication, vector processing and more. AMVP leverages many of the message flows originally defined for ACVP and incorporates them into a module-specific concept and adds new flows for module test evidence submission and validation requests.
Protocol Overview#
AMVP has the following goals:
To communicate registration information for one to many cryptographic modules for lab, vendor, module and OE.
To submit test evidence as defined by FIPS SP 800-140Br1.
To enable automated registration and test evidence submission with minimal human interaction.
To provide extensibility that can be used to introduce registration for new module types and new test evidence as needed.
To be compatible with emerging automated validation systems wherever possible, especially the FIPS-140 Cryptographic Module Validation Program.
AMVP defines how to communicate registration information, test evidence and validation requests with a validation authority. It is dependent upon existing technologies such as HTTPS, JSON and TLS to perform the message exchanges. In addition it is dependent on submissions to the validation authority from ACVP and the ESV protocol. The relationship between the three protocols can be summarized as follows.
AMVP registers the lab, vendor, module and OE information.
ACVP performs algorithm testing on an OE and submits the results assigned to the module/OE registered by AMVP.
ESV performs entropy testing on an OE and submits the results assigned to the module/OE registered by AMVP.
AMVP submits additional module-centric test evidence and documentation to meet FIPS SP 800-140Br1 requirements.
AMVP submits a request for FIPS 140-3 module validation.
Protocol Audience#
This document is written to address multiple audiences:
Crypto module developers who require validation testing
Crypto validation organizations who will perform validation testing
Crypto module customers that desire validation testing results or verifiable artifacts of testing
Goals#
The goals for this document are to provide a messaging protocol that can be used with existing authentication and communication protocols to provide a way to validate crypto modules. The following functions are outside the scope of this document:
The API to the cryptographic module
Where AMVP is located within the client premise
How the results/artifacts are stored or managed
Scalability
Management interface
Strategy#
To meet the goals laid out here the strategy must be:
To perform module registration in such a way the server is able to limit requests to only applicable evidence sets
To provide evidence that avoids free text and replaces it with structured reproducible schema so it is automatable
To provide registration such that information is available to generate a security policy which meets SP 800-140B
Architecture#
A server/client/proxy model is used where the roles are defined as:
-
AMV Client/Proxy - Communicates with the AMV server using Java Script Object Notation (JSON [RFC7159]) and submits registration for various resources and test evidence that is module-centric.
-
AMV Server - Maintains registration information and processes test evidence for module validation requests.
Terminology
The following terms are consistently used throughout this document and SHOULD be used throughout its extensions:
-
Registration - The JSON from the client to the server that describes the capabilities for which the client is seeking test cases and a validation. Evidence required will be broken into individual Test evidenceSets.
-
Request - The JSON sent from the server to the client defining a single Test evidenceSet to use as inputs for testing. Exactly one request will exist for each Test evidenceSet.
-
Response - The JSON from the client providing the desired output for each of the Test Cases defined in the corresponding Request file. These are linked via the Test evidenceSet evId. As exactly one request exists for each esId, one response will exist for each request.
-
Disposition - The JSON from the server after the Response is submitted by the client detailing the correctness of the Test Evidence. A "passed" disposition indicates that the particular test in the Test evidenceSet is ready for validation.
-
OE - Operational Environment - The specific hardware and/or software the client’s cryptographic implementation uses to run.
AMV Protocol#
The AMV protocol will utilize existing mechanisms for transport coordinated with JSON formatted messaging.
+-----------------------------------------------+ | JSON Formatted AMVP request/response messages | +-----------------------------------------------+ | HTTP[S] message transfer and signaling | +-----------------------------------------------+ | TLS for transport security (recommended) | +-----------------------------------------------+ | TCP for transport | |_______________________________________________|
HTTP URI Hierarchy
+-------------+------+-----------+
| server |path | resource
| |prefix|
+-------------+------+-----------+
https://amvts.nist.gov/amvp/v1/certRequests
+-------------+------+-----------+
version
Note that deployments utilizing AMV Proxy server MAY use a different protocol, e.g., HTTP, custom server, context and port number to interact with the DUT.
HTTP URI Resources
In the table below, any parts of a resource path enclosed in curly braces, { or }, are replaced by an instance of what is described in the braces. For example {requestId} could be replaced with 1.
An empty cell for a resource and HTTP Method combination denotes that the server returns an HTTP Status 405 code Method not allowed (405).
Resource |
GET (read) |
POST (create) |
PUT (update) |
/certRequests |
|||
/modules/{moduleId} |
|||
/certRequests/{certRequestId} |
|||
/certRequests/{certRequestId}/functionalTest |
|||
/certRequests/{certRequestId}/sourceCode |
|||
/certRequests/{certRequestId}/securityPolicy |
|||
/certRequests/{certRequestId}/securityPolicy/template |
|||
/certRequests/{certRequestId}/otherDocumentation |
|||
/certRequests/{certRequestId}/certify |
|||
/schemas |
|||
/schemas/{endpoint} |
|||
/schemas/{endpoint}/{version} |
The resource path is appended to the path prefix to form the URI used with an HTTP Method to perform the desired AMVP operation. For example to create a new test session using the "/certRequests" resource is "/amvp/v1/certRequests" (assuming an empty context). To create a new certificate request session, the AMVP client would use the following HTTP request-line:
POST /amvp/v1/certRequests HTTP/1.1
Security#
HTTPS and TLS 1.2 or greater SHALL be used in order to enforce a secure communication method.
Authentication
A JSON Web Token (JWT) SHALL be created by the server upon successful client authentication and returned to the client to use as an authorization mechanism for accessing the server resources - see JSON Web Token (JWT) below for more information. Since AMVP is targeted for validation authorities only, it SHALL use TLS mutual certificate authentication.
The client SHALL return the token to the server via the Authorization Bearer header in all subsequent HTTP requests.
The server MAY provide a JWT that includes additional claims. The claims will link the user to a set of data created by the user. If the user wishes to interact with that data, the user SHALL use the JWT with the claims.
JSON Web Token (JWT)
JSON Web Token is described in [RFC7519] and is used as an authorization mechanism for gaining access to different resources.
The JWT can be secured if desired using the header encryption "alg" value defined to HS256(HMAC-SHA256) or one of the other secure values. Key agreement would follow RFC7518.
{
"alg": "HS256",
"typ": "JWT"
}
{
"iss" : "NIST AMVP",
"nbf": 1598293915,
"exp": 1598295715,
"iat": 1598293915,
"pkey" : "cc74f56acdba635079383a03941d68db55c7b3c2f (truncated)"
}
{
"{signature}"
}where "{signature}" is made up of:
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
and where "HMACSHA256" is the algorithm specified in the JWT header.
The first four claims are required, however "pkey" is an optional private claim used to pass the key used for encrypting the database at the server. Enabling this option is discussed further in [certRequests_post]
Authorization flows with JWT
JSON Web Token is described in [RFC7519] and is used as an authorization mechanism for gaining access to different resources.
In order to access any resource which requires authorization a client must supply the JWT
as an Authorization header value as a Bearer token. An example header value is:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5c (truncated)"
Workflow authorization flows. All exchanges shown are over HTTP.
+--------+---------------------------------+------+--------+
| Client | |Server| Notes |
+--------+---------------------------------+------+--------+
| |POST to /login or similar with | | |
| |appropriate credentials | | |
| |-------------------------------->| | |
| | | | |
| |receive the access token | | |
| |<- - - - - - - - - - - | | |
| | | | |
POST: [{"passcode":"66008332"}]
200 OK: [{"accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....}]
JWT Expiration/Renewal
The JWT access tokens received from either the /login server endpoint SHALL be set to expire after a pre-defined period. The specific length of the expiration period is out of scope for this specification. However, the expiration period length impacts both the security and protocol overhead. Longer expiration periods reduce the overhead but increase the window for attacks. Attempting to access a service with an expired JWT SHALL result in a "401 Unauthorized" HTTP status code.
A client may renew an expired JWT access token using the mechanism shown in Renewal Flows below.
JWT access token renewal flows. All exchanges shown are over HTTP.
+--------+---------------------------------+------+--------+
| Client | |Server| Notes |
+--------+---------------------------------+------+--------+
| |POST to /login or similar with | | |
| |appropriate credentials | | |
| |and expired JWT access token | | |
| |-------------------------------->| |session |
| | | |or |
| | | |login |
| | | |JWT |
| |receive the renewed access token | | |
| |<- - - - - - - - - - - | | |
Server returns 401
POST: [[{"passcode":"47682787","accessToken":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....}]]
200 OK: [{"accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.....}]
Login#
A login endpoint (at /amvp/v1/login) is mentioned throughout the document and how to authenticate is defined by the server. The following defines how the login endpoint to establish a session and obtain a [jwtAuthFlows].
-
passcode -
string, a property for providing a passcode value -
accessToken -
string, a JWT associated with the current user for which renewal of the expiration is desired
Request
There are two forms of a login request. There is the initial form which just provides the authentication information without any JWT, and there is a renewal login that allows a user to obtain a new JWT containing the claims from an expired JWT in order to access a resource protected with those claims.
POST /login (Initial)
{
"amvVersion": "0.1",
"passcode": "{passcode}"
}POST /login (Renewal)
{
"amvVersion": "0.1",
"passcode": "{passcode}",
"accessToken": "{jwt value}"
}Response
{
"accessToken": "{jwt value}",
"amvVersion": "0.1"
}Multi Refresh JWT
This endpoint can be utilized for refreshing multiple JWTs with a single POST. Because a JWT with claims is issued for each test session created and clients have the option of performing more than one test session at a time, a mechanism for refreshing multiple JWTs across multiple test sessions simultaneously MAY be made available.
Request
POST /login/refresh
{
"amvVersion": "0.1",
"passcode": "{passcode}",
"accessToken": [
"{jwt1}",
"{jwt2}",
"..."
]
}Response
{
"accessToken": [
"{newJwt1}",
"{newJwt2}",
"..."
],
"amvVersion": "0.1"
}Note the order of JWTs between the request and response is preserved.
In the event of an error occurring during any of the above requests, the AMVP server MUST respond with a error response formatted as defined by section 11 of this specification. The category codes and error codes to use are defined by Table 1 below.
Category Code |
Scenario |
Error code |
1 |
Expected an access token but was not provided |
1 |
A provided access token did not verify |
2 |
|
A provided access token has expired |
3 |
|
The provided "passcode" was incorrect |
4 |
|
2 |
Provided payload is not valid JSON |
1 |
3 |
JSON payload not in array format |
1 |
JSON missing initial expected amvVersion |
2 |
|
Provided amvVersion is invalid or not supported |
3 |
|
JSON missing other expected value |
4 |
|
Wrong data type used for expected value |
5 |
|
Data for given value is invalid |
6 |
Note: The login endpoints are unique in that the payload contents are specific to the end user for authentication. This is why the errors fall under category 1 instead of category 3, which handles more general cases of all other semantically incorrect JSON.
When using the multi refresh JWT process described above, the AMVP server SHALL include an error object for each separate JWT that encounters an error.
Versioning#
The version of the AMVP protocol will be carried with each message and will contain a simple major.minor format. Major version changes will not be backward compatible, however additions and enhancements that do not disrupt compatibility will be indicated with a minor version change. A server MAY accept a down-level version from the client if it can process at a lower level. If not, it will reject the session. All subsequent messages will carry the negotiated version value.
The version is represented in all messages to and from the server with the following format.
{
"amvVersion": "0.1",
<message payload>
}Messaging#
The general flow of the protocol is to:
-
Login to the system via
POST /amvp/v1/login -
Create a certificate request session and register a module via
POST /amvp/v1/certRequests -
Submit functional test evidence (FT-TE) via
POST /amvp/v1/certRequests/<id>/functionalTest -
Submit source code test evidence (SC-TE) via
POST /amvp/v1/certRequests/<id>/sourceCode -
Submit other docmumentation test evidence (OD-TE) via
POST /amvp/v1/certRequests/<id>/otherDocumentation -
Submit security policy evidence via
POST /amvp/v1/certRequests/<id>/securityPolicy -
Submit security policy template via
POST /amvp/v1/certRequests/<id>/securityPolicy/template -
Generate the security policy via
PUT /amvp/v1/certRequests/<id>/securityPolicy -
Certify the submission via
POST /amvp/v1/certRequests/<id>/certify -
Receive the validation certificate via
GET /amvp/v1/certRequests/<id>
Details on the specific requests, payloads, and responses are covered in this section.
Resource Registration Exchange
The registration will utilize the URI resources [xml_uriResources] to register various resources associated with the module as well as module specific capabilities. This exchange will consist of several message exchanges and will provide a detailed list of module capabilities to be registered, see [xml_regmsgFlows]. A set of URI resources are also available to retrieve and manage the available metadata. The registration can be performed at any time prior to formal algorithm testing, formal entropy testing and the formal module validation request.
Test Evidence Exchange
The test evidence exchange consists of the AMV client initiating a certRequest and then requesting evidenceSet(s) associated with the request. An evidenceSet may require a test to be performed or some documentation to be gathered and then presented to the server as test evidence. The client MAY retrieve and process the evidenceSets in any order. The client MAY retrieve an evidenceSet and immediately return results, or it MAY return results at a later time. The client repeats this process until all of the evidenceSets in the certRequest list have been processed. Once an evidenceSet result has been POSTed to the server the client may request success/failure results from the server at any time; however, if evidenceSets have not been completed, the overall status will be incomplete. A message flow overview is described below [xml_msgFlows].
Module Validation Request
Once a certRequest result has successfully completed the client will receive a module validation certificate, via GET on the certRequest session.
Message Flows
Message flows are provided in Appendix A, but the content and responses provided here are the expected content.
Schema Requests
Schema requests exist outside of the mandatory flow. They act as a supplemental endpoint that clients may reference when creating their payloads for other endpoints.
Retrieve All Schema Endpoints
GET /schemas
Returns a list of all available endpoints to retrieve schemas for.
Response
{
"endpointList": [
"certificateRequestRegister",
"functionalTest",
"otherDocumentation",
"securityPolicy",
"sourceCode"
],
"amvVersion": "0.1"
}View Endpoint Schema Version
GET /schemas/<endpoint>
Returns a list of schema versions and their statuses for an endpoint.
Response
{
"schemaList": [
{
"endpoint": "certificateRequestRegister",
"version": "0.2",
"status": "deprecated"
},
{
"endpoint": "certificateRequestRegister",
"version": "0.3",
"status": "deprecated"
},
{
"endpoint": "certificateRequestRegister",
"version": "0.4",
"status": "preferred"
}
],
"amvVersion": "0.1"
}View Schema
GET schemas/<endpoint>/<version>
Returns the schema for the specified endpoint and version.
Response
{
"endpoint": "certificateRequestRegister",
"version": "0.4",
"status": "preferred",
"schema": {
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "certificateRequestRegisterPayload",
"title": "certificateRequestRegisterPayload",
"description": "Certificate Request Register payload JSON schema",
"type": "object",
"additionalProperties": false,
"required": [
"amvVersion",
"vendorId",
"moduleId",
"testers",
"module"
],
"properties": {
"amvVersion": {
"type": "string"
},
"vendorId": {
"type": "integer"
},
"moduleId": {
"type": "integer"
},
"testers": {
"type": "array",
"items": {
"type": "string"
}
},
"module": {
"description": "The module registration information to be submitted",
"type": "object",
"additionalProperties": false,
"required": [
"schemaVersion",
"moduleInfo",
"secLevels",
"filterProperties"
],
"properties": {
"schemaVersion": {
"type": "string"
},
"moduleInfo": {
"type": "object",
"additionalProperties": false,
"properties": {
"count": {
"type": "integer"
},
"embodiment": {
"type": "string"
},
"opEnvType": {
"type": "string"
},
"submissionLevel": {
"type": "string"
},
"itar": {
"type": "boolean"
},
"overallSecurityLevel": {
"type": "integer"
}
},
"required": [
"count",
"embodiment",
"opEnvType",
"submissionLevel",
"overallSecurityLevel"
]
},
"secLevels": {
"type": "array",
"items": {
"type": "object",
"properties": {
"section": {
"type": "integer"
},
"level": {
"type": "integer"
}
}
}
},
"filterProperties": {
"type": "array",
"items": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"included": {
"type": "boolean"
}
}
}
}
}
}
}
},
"amvVersion": "0.1"
}Module Requests
Retrieve information for a Module
GET /modules/{moduleId}
Returns information about a specific module. The information is provided based on the moduleInfo section registered with the module when creating a new certificate request session. The moduleId can be found from a GET amvp/v1/certRequests/{certRequestId} on a successfully registered certificateRequestId.
Response
{
"id": 165,
"name": "OpenSSL FIPS Provider",
"description": "FIPS Provider V3.0.0",
"embodiment": "Single Chip",
"type": "software",
"opEnvType": "Intel X86_64",
"overallSecurityLevel": 1,
"amvVersion": "0.1"
}Certificate Request Sessions
Create a New Certificate Request Session
POST /certRequests
Create a new Certificate Request Session.
Request
{
"amvVersion": "0.1",
"vendorId": 1,
"moduleId": 1,
"testers": [
"CVP-0-000001",
"CVP-0-000002"
],
"module":
{
"schemaVersion": "initial",
"moduleInfo":
{
"count": 1,
"embodiment": "singlechip",
"opEnvType": "modifiable",
"submissionLevel": "Level 1",
"itar": false,
"overallSecurityLevel": 2
},
"secLevels":
[
{
"section": 1,
"level": 1
},
{
"section": 2,
"level": 1
},
{
"section": 3,
"level": 1
},
{
"section": 4,
"level": 1
},
{
"section": 5,
"level": 1
},
{
"section": 6,
"level": 1
},
{
"section": 7,
"level": 1
},
{
"section": 8,
"level": 1
},
{
"section": 9,
"level": 1
},
{
"section": 10,
"level": 1
},
{
"section": 11,
"level": 1
},
{
"section": 12,
"level": 1
}
],
"filterProperties":
[
{"name": "implementsOtar", "included": true},
{"name": "hasNonApprovedMode", "included": true},
{"name": "requiresInitialization", "included": true},
{"name": "hasExcludedComponents", "included": true},
{"name": "hasDegradedMode", "included": false},
{"name": "hasPAAorPAI", "included": false},
{"name": "hasEmbeddedOrBoundModule", "included": false},
{"name": "hasCriticalFunctions", "included": false},
{"name": "hasNonApprovedsInApprovedMode", "included": false},
{"name": "hasExternalInputDevice", "included": false},
{"name": "hasExternalOutputDevice", "included": false},
{"name": "usesTrustedChannel", "included": true},
{"name": "supportsConcurrentOperators", "included": true},
{"name": "usesIdentityBasedAuthentication", "included": true},
{"name": "hasMaintenanceRole", "included": true},
{"name": "allowsOperatorToChangeRoles", "included": false},
{"name": "hasDefaultAuthenticationData", "included": true},
{"name": "usesEDC", "included": true},
{"name": "allowsExternalLoadingOfSoftwareOrFirmware", "included": false},
{"name": "containsNonReconfigurableMemory", "included": true},
{"name": "usesOpenSource", "included": false},
{"name": "providesMaintenanceAccessInterface", "included": false},
{"name": "hasVentilationOrSlits", "included": false},
{"name": "hasRemovableCover", "included": false},
{"name": "hasTamperSeals", "included": false},
{"name": "hasOperatorAppliedTamperSeals", "included": false},
{"name": "hasEFPorEFT", "included": false},
{"name": "outputsSensitiveDataAsPlaintext", "included": false},
{"name": "supportsManualSSPEntry", "included": true},
{"name": "usesSplitKnowledge", "included": true},
{"name": "hasCVE", "included": true},
{"name": "hasAdditionalMitigations", "included": false},
{"name": "usesOtherCurve", "included": true},
{"name": "supportsBypassCapability", "included": false},
{"name": "hasOTPMemory", "included": false},
{"name": "hasEFP", "included": false},
{"name": "hasEFT", "included": false},
{"name": "hasUserRole", "included": false},
{"name": "allowsSelfInitiatedCryptographicOutput", "included": false},
{"name": "usesAuthentication", "included": false},
{"name": "usesHashMacIntegrity", "included": false},
{"name": "usesDigitalSignatureIntegrity", "included": false},
{"name": "supportsSensitiveDataIO", "included": false},
{"name": "supportsCompleteImageReplacement", "included": false},
{"name": "hasControlOutput", "included": false},
{"name": "usesRoleBasedAuthentication", "included": false}
]
}
}
Response
The accessToken is a [RFC7519] which MUST be supplied as described in [jwtToken] in order to access the Certificate Request Session.
{
"url": "/amvp/v1/certRequests/2",
"vendorId": 1,
"status": "initial",
"accessToken" : "eyJhbGciOiJIUzI1NiIsInR5cCI6Ik (truncated)",
"amvVersion": "0.1",
}Certificate Request Session Information
GET /certRequests/{certRequestId}
Returns information about the specific Certificate Request Session. Several different responses could be provided depending on the status of the certRequest.
Response
If the certRequest is still in the initial state, the following response will be provided, indicating the client to try to access the resource again after retry seconds.
{
"amvVersion": "0.1",
"certRequestId": 2,
"retry": 30,
"status": "initial"
}If the certRequest is in the ready state, the following response will be provided. This indicates which test requirements the server determined to be applicable to the module based on the registration. The client shall provide evidence for each test requirement and the client shall provide security policy information in order for the certRequest to advance to the requirementsSubmitted state.
{
"url": "/amvp/v1/certRequests/8",
"moduleId": 2,
"vendorId": 1,
"status": "ready",
"securityPolicyStatus": "acceptingSubmissions",
"evidenceStatus": "acceptingSubmissions",
"missingSPTemplate": true,
"missingSecurityPolicySubmission": true,
"evidenceList": [
{
"te": "TE02.10.01",
"required": [],
"oneOf": [
{
"types": [
"SC-TE",
"FT-TE"
],
"submitted": []
}
],
"complete": false
},
{
"te": "TE02.12.01",
"required": [
{
"types": [
"FT-TE"
],
"submitted": []
}
],
"oneOf": [],
"complete": false
},
{
"te": "TE02.19.02",
"required": [
{
"types": [
"FT-TE"
],
"submitted": []
}
],
"oneOf": [],
"complete": false
},
{
"te": "TE02.22.02",
"required": [
{
"types": [
"FT-TE"
],
"submitted": []
}
],
"oneOf": [],
"complete": false
}
],
"amvVersion": "0.1"
}If the certRequest’s FT-TE, SC-TE, OD-TE and SP-TE evidence are submitted, it will be in the requirementSubmitted state, the following response will be provided. The FT-TE and SC-TE status will either be in processing or submitted state. The SP-TE can be in processingGeneration, pendingGeneration, or submitted state.
{
"url": "/amvp/v1/certRequests/745",
"moduleId": 262,
"vendorId": 1,
"status": "requirementsSubmitted",
"securityPolicyStatus": "pendingGeneration",
"evidenceStatus": "submitted",
"amvVersion": "0.1"
}After FT-TE, SC-TE, OD-TE and SP-TE evidence are POSTed and SP-TE is PUTed, the following response will be provided.
{
"url": "/amvp/v1/certRequests/746",
"moduleId": 263,
"vendorId": 1,
"status": "requirementsSubmitted",
"securityPolicyStatus": "submitted",
"functionalTestStatus": "submitted",
"sourceCodeStatus": "submitted",
"amvVersion": "0.1"
}Certificate Request Functional Test Evidence (FT-TE) Submission
POST /certRequests/{certRequestId}/functionalTest
This endpoint allows a client to submit functional test evidence as requested by the server via the GET /certRequests/{certRequestId} response. Each test requirement is stored individually on the server and can be overwritten at any time with another POST. Subsequent GET /certRequests/{certRequestId} will update to reflect any remaining test requirements which need evidence submitted.
{
"amvVersion": "0.1",
"functionalTest":
{
"document":
{
"base-catalogVersion": "3.0",
"base-lastUpdated": "October-16-2023",
"functionalTesting-EC": "0.6",
"functionalTesting-lastUpdated": "October-29-2024"
},
"testEvidence":
[
{
"teList":
[
"TE02.12.01"
],
"description": "Verify that versioning info identifies distinct components.",
"access": "physical",
"technique": "debugger simulation emulation harness manual other",
"setup": "reference into Catalog",
"errorInduction": "description of",
"results":
{
"summary": "sample summary",
"digest": "000000",
"fileLocation": "location of test evidence",
"integrityMechanism": "SHA2-512"
}
}
]
}
}Certificate Request Source Code Evidence (SC-TE) Submission
POST /certRequests/{certRequestId}/sourceCode
This endpoint allows a client to submit source code evidence as requested by the server via the GET /certRequests/{certRequestId} response. Each test requirement is stored individually on the server and can be overwritten at any time with another POST. Subsequent GET /certRequests/{certRequestId} will update to reflect any remaining test requirements which need evidence submitted.
{
"amvVersion": "0.1",
"sourceCode": {
"document": {
"base-catalogVersion": "3.0",
"base-lastUpdated": "October-16-2023",
"sourceCode-EC": "0.6",
"sourceCode-lastUpdated": "October-29-2024"
},
"testEvidence": [
{
"teList": [
"TE02.10.01",
"TE02.07.01",
"TE02.07.02"
],
"file": [
"full path to file"
],
"function": "Source code method/function(s)",
"lines": "Source code line numbers",
"description": "Summarize how the source code review aspect of the TE was accomplished.",
"input": "may not always be applicable",
"output": "may not always be applicable",
"status": "",
"results":
{
"summary": "sample summary",
"digest": "000000",
"fileLocation": "location of test evidence",
"integrityMechanism": "SHA2-512"
}
}
]
}
}Certificate Request Other Documentation Evidence (OD-TE) Submission
POST /certRequests/{certRequestId}/otherDocumentation
This endpoint allows a client to submit other documentation evidence as requested by the server via the GET /certRequests/{certRequestId} response. Each test requirement is stored individually on the server and can be overwritten at any time with another POST. Subsequent GET /certRequests/{certRequestId} will update to reflect any remaining test requirements which need evidence submitted.
{
"amvVersion": "0.1",
"otherDocumentation": {
"document": {
"base-catalogVersion": "3.0",
"base-lastUpdated": "October-16-2023",
"otherDocumentation-EC": "0.6",
"otherDocumentation-lastUpdated": "October-29-2024"
},
"testEvidence": [
{
"teList": [
"TE02.03.02"
],
"documents":
[
{
"sectionName": "sample",
"documentName": "sampleDocument",
}
],
"results":
{
"summary": "sample summary",
"digest": "000000",
"fileLocation": "location of test evidence",
"integrityMechanism": "SHA2-512"
}
}
]
}
}Certificate Request Security Policy Submission
POST /certRequests/{certRequestId}/securityPolicy
This endpoint allows a client to submit missing security policy information as requested during the GET /certRequests/{certRequestId}. Each security policy is stored individually on the server and can be overwritten at any time with another POST. Subsequent GET /certRequests/{certRequestId} will update to reflect any remaining security policy sections that need information submitted.
{
"amvVersion": "0.1",
"securityPolicy": {
"schemaVersion": "2.8.4",
"cavpCertSet": {
"cavpCertList": [
{
"vendorName": "Duis ea",
"certName": "in sed nulla do dolor",
"validationId": 11023992,
"implName": "exercitation tempor ad",
"implVersion": "ut sed cillum",
"implType": "esse est ea quis cillum",
"implOrganization": "magna ipsum aliqua proident sit"
}
],
"cavpOeList": [
{
"name": "consectetur do cupidatat Ut",
"oeId": 3
}
],
"cavpOeAlgoList": [
{
"validationOeAlgorithmId": 1,
"algoDisplayName": "exercitation ad",
"canonicalAlgorithmId": 1,
"validationId": 1,
"certName": "anim fugiat nisi Lorem enim",
"implName": "velit exercitation irure magna eu",
"oeId": 8308,
"selectedCapList": [
{
"capabilityId": 31642322,
"displayText": "esse",
"childCapabilities": []
}
]
}
],
"cavpImplAlgoList": [
{
"algoDisplayName": "AES-CBC",
"canonicalAlgorithmId": 1,
"implName": "in Lorem",
"validationId": 7,
"certName": "nisi ex sint",
"category": "laboris velit"
}
],
"cavpItarAlgoList": [
{
"certName": "elit esse est",
"algoDisplayName": "AES-CBC-CS3",
"canonicalAlgorithmId": 4,
"capabilities": "deserunt est sed ad eiusmod",
"category": "Duis mollit magna"
}
]
},
"esvCertList": [
{
"esvCertName": "laboris veniam sunt dolore reprehenderit",
"certId": 33293608,
"vendorName": "cupidatat sit amet sunt"
}
],
"esvItarCertList": [
"pariatur",
"Lorem"
],
"testedHwList": [
{
"modelPartNum": "sint aute cillum quis",
"hwVersion": "et cupidatat",
"fwVersion": "consequat",
"processors": "consequat",
"features": "laborum id exercitation laboris veniam"
}
],
"testedSwFwHyList": [
{
"packageFileName": "laborum commodo consectetur nulla",
"swFwVersion": "magna",
"features": "anim Ut dolor occaecat in",
"integrityTest": "consequat ipsum dolor elit"
}
],
"testedHyHwList": [
{
"modelPartNum": "quis ullamco",
"hwVersion": "nisi laboris",
"fwVersion": "aliquip Lorem est in tempor",
"processors": "mollit sunt",
"features": "cupidatat"
}
],
"opEnvSwFwHyTestedList": [
{
"operatingSystem": "nostrud aliquip proident",
"hardwarePlatform": "in ut enim quis irure",
"processors": "nulla cupidatat",
"paaPai": "esse",
"hypervisorHostOs": "Excepteur ipsum labore elit",
"swFwVersionList": [
"deserunt est consequat pariatur ex",
"tempor dolor eiusmod",
"ipsum dolor",
"Ut cupidatat",
"et consequat"
]
}
],
"opEnvSwFwHyVAList": [
{
"operatingSystem": "reprehenderit culpa ut",
"hardwarePlatform": "pariatur esse in consectetur"
}
],
"modeOfOpList": [
{
"name": "officia commodo",
"description": "in ipsum",
"type": "aliquip",
"statusIndicator": "laborum"
}
],
"vendorAffirmedAlgoList": [
{
"name": "in ad in",
"algoPropList": [
{
"name": "id velit anim Ut veniam",
"value": "enim voluptate",
"propertyId": 11387443
}
],
"implName": "sed Excepteur",
"reference": "ullamco culpa"
}
],
"nonApprovedAllowedAlgoList": [
{
"name": "deserunt laboris non",
"algoPropList": [
{
"name": "ea aute consectetur Duis",
"value": "in ut",
"propertyId": -57056207
}
],
"implName": "incididunt enim anim",
"reference": "consectetur"
}
],
"nonApprovedAllowedAlgoNSCList": [
{
"name": "quis in",
"caveat": "ut adipisicing",
"useFunction": "non eu"
}
],
"nonApprovedNotAllowedAlgoList": [
{
"name": "in Ut incididunt",
"useFunction": "irure"
}
],
"secFunImplList": [
{
"name": "nostrud ex",
"sfTypeList": [
{
"sfAbbrev": "ad Excepteur sed id",
"sfId": 53184293
}
],
"description": "ad quis irure nisi",
"sfPropList": [
{
"name": "non veniam sint tempor occaecat",
"value": "et",
"propertyId": -30179093
}
],
"algorithmList": [
{
"algoDisplayName": "magna cupidatat laborum Ut in",
"canonicalAlgorithmId": 47899832,
"implName": "velit laborum sint id nostrud",
"validationId": 5,
"algoPropList": [],
"certName": "et"
}
]
}
],
"entropySourceList": [
{
"name": "labore ex",
"type": "reprehenderit",
"opEnv": "eu est",
"sampleSize": "exercitation",
"entropyPerSample": "cillum laborum",
"conditioningComp": "fugiat"
}
],
"portInterfaceList": [
{
"physicalPort": "ullamco",
"logicalInterfaceList": [
"ex qui velit eu",
"est",
"Duis sit labore aute ex",
"laborum fugiat adipisicing"
],
"dataPasses": "ullamco voluptate in ut veniam"
}
],
"authMethodList": [
{
"name": "labore exercitation dolore do dolore",
"description": "deserunt non ut",
"mechanism": "nostrud culpa",
"strengthEachAttempt": "exercitation reprehenderit dolor sed cillum",
"strengthPerMin": "deserunt"
}
],
"roleList": [
{
"name": "aliquip fugiat",
"type": "sint ut dolore Duis veniam",
"operatorType": "ea elit aliquip officia",
"authMethodList": [
"adipisicing Ut in",
"velit cillum cupidatat consectetur",
"labore adipisicing",
"Ut"
]
}
],
"approvedServiceList": [
{
"name": "ut",
"description": "labore eu irure",
"indicator": "qui",
"inputs": "ea cupidatat ullamco pariatur irure",
"outputs": "Ut aute",
"secFunImplList": [
"in",
"minim sed",
"ad pariatur"
],
"roleSspAccessList": [
{
"roleName": "aute esse do laborum",
"sspAccessList": [
{
"sspName": "quis consequat tempor laboris reprehenderit",
"accessType": [
"veniam laborum tempor",
"cupidatat aute",
"ut esse sint Lorem",
"culpa nulla",
"sit consequat incididunt occaecat"
]
}
]
},
{
"roleName": "incididunt id adipisicing et",
"sspAccessList": [
{
"sspName": "amet esse",
"accessType": [
"sunt dolore mollit",
"ipsum incididunt nisi in"
]
}
]
},
{
"roleName": "non Lorem est incididunt sit",
"sspAccessList": [
{
"sspName": "reprehenderit pariatur nisi sed",
"accessType": [
"consequat",
"amet"
]
}
]
},
{
"roleName": "non enim proident ex",
"sspAccessList": [
{
"sspName": "dolor voluptate",
"accessType": [
"aliquip esse",
"et laborum eiusmod veniam"
]
}
]
},
{
"roleName": "elit",
"sspAccessList": [
{
"sspName": "do sit dolor",
"accessType": [
"veniam ad do",
"irure"
]
}
]
}
]
}
],
"nonApprovedServiceList": [
{
"name": "anim quis elit",
"description": "commodo et deserunt",
"nonApprovedAlgoList": [
"nisi ea incididunt deserunt",
"Duis cillum",
"voluptate elit aute in",
"veniam"
],
"role": "exercitation aliquip"
}
],
"phSecMechanismList": [
{
"mechanism": "sunt",
"inspectFreq": "quis cupidatat in",
"inspectGuidance": "ullamco nulla in commodo sit"
}
],
"efpEftInfoList": [
{
"tempVoltType": "ullamco non",
"tempVolt": "non irure consectetur mollit",
"efpOrEft": "consectetur",
"result": "ad"
}
],
"hardnessTestTempList": [
{
"tempType": "aute veniam",
"temp": "culpa in"
}
],
"storageAreaList": [
{
"name": "sit exercitation nostrud veniam",
"description": "aliquip amet dolor deserunt Lorem",
"persistenceType": "sit consectetur ad ipsum irure"
}
],
"sspInputOutputList": [
{
"name": "aliquip do",
"from": "eu sint amet Duis Excepteur",
"to": "Excepteur commodo",
"formatType": "magna",
"distributionType": "dolor ea nostrud laboris ut",
"entryType": "officia voluptate ipsum adipisicing",
"relatedSFI": "non irure"
}
],
"sspZeroizationList": [
{
"method": "sint in",
"description": "veniam",
"rationale": "nostrud",
"operatorInitiation": "culpa cillum proident"
}
],
"sspList": [
{
"name": "nulla",
"description": "in non minim",
"size": "id",
"strength": "Lorem consequat sunt mollit",
"type": "id",
"generatedByList": [
"est",
"mollit in dolor eu Duis",
"irure exercitation est commodo",
"anim eu aliqua Excepteur",
"ullamco ad mollit"
],
"establishedByList": [
"anim eiusmod",
"sed enim tempor",
"officia cillum ex nostrud",
"elit voluptate amet laborum labore",
"Duis amet culpa"
],
"usedByList": [
"quis",
"proident",
"adipisicing ea mollit",
"cupidatat nisi incididunt dolore",
"voluptate tempor"
],
"inputOutputList": [
"aliqua ut nisi consequat",
"nulla in cillum est"
],
"storageItemList": [
{
"areaName": "est consequat dolore",
"format": "in",
"algorithmName": "ad"
}
],
"storageDuration": "nostrud",
"zeroizationList": [
"ad nostrud occaecat",
"minim ad incididunt irure",
"aute eiusmod"
],
"category": "elit do aliquip",
"relatedSspList": [
{
"sspName": "quis laborum qui",
"relationship": "mollit laborum nostrud in ut"
}
]
}
],
"preOpSelfTestList": [
{
"algorithmOrTest": "reprehenderit exercitation commodo velit",
"testProps": "ullamco nostrud",
"testMethod": "amet sit minim",
"type": "veniam",
"indicator": "ut irure pariatur adipisicing",
"details": "labore voluptate nisi",
"period": "in eu ex",
"periodicMethod": "in eu officia minim"
}
],
"condSelfTestList": [
{
"algorithmOrTest": "sed laboris Ut",
"testProps": "culpa",
"testMethod": "ea",
"type": "laborum dolore tempor nisi",
"indicator": "sit sed cillum qui",
"details": "enim adipisicing eu cupidatat amet",
"conditions": "amet laboris",
"coverage": [],
"coverageNotes": "velit culpa officia",
"period": "sit",
"periodicMethod": "dolor reprehenderit Duis"
}
],
"errorStateList": [
{
"name": "velit in",
"description": "ex",
"conditions": [
"reprehenderit nostrud cillum anim labore",
"do dolor officia",
"adipisicing voluptate do tempor"
],
"recoveryMethod": "aliquip",
"indicator": "irure amet"
}
],
"referenceList": [
"do occaecat sunt",
"irure velit"
]
}
}Security Policy Template Submission
POST /certRequests/{certRequestId}/securityPolicy/template
This endpoint allows a client to submit security policy templates. Data is submitted as form-data.
| Key | Type | Value |
|---|---|---|
amvVersion |
string |
"0.1" |
documentTemplate |
file |
<SP Template File> |
Security Policy Information Document Generation
PUT /certRequests/{certRequestId}/securityPolicy
This endpoint allows a client to generate security policy information in .docx format. Security Policy must be submitted before this action. No payload is needed to submit the PUT request.
After PUT request, the following response will be provided. To view the .docx file generation status, use GET certRequests/{cerRequestId} as above. "securityPolicyStatus" will become "submitted" after .docx file is generated.
Response
{
"url": "/amvp/v1/certRequests/549",
"moduleId": 190,
"vendorId": 1,
"status": "requirementsSubmitted",
"securityPolicyStatus": "processingGeneration",
"evidenceStatus": "submitted",
"amvVersion": "0.1"
}Get Security Policy Information
GET /certRequests/{certRequestId}/securityPolicy
This endpoint allows a client to get security policy information as a .docx file.
Response
{
"status": "success",
"content": "JVBERi0xLjQKJZOMi54gUmVwb3J0TGFiI(truncated) ",
"digest": "qXHfhkXrVJQlTk4Wsa1RwfqmxPS8jxPvZfz4XwjGSOc=",
"dateTime": "2025-01-23T18:22:51.717",
"amvVersion": "0.1"
}Post Certify
POST /certRequests/{certRequestId}/certify
This endpoint allows a client to certify the certificate.
Response
{
"url": "/amvp/v1/certRequests/549",
"moduleId": 190,
"vendorId": 1,
"status": "requirementsSubmitted",
"securityPolicyStatus": "submitted",
"evidenceStatus": "submitted"
"amvVersion": "0.1"
}After POST /certify request is completed, GET /certRequests/{certRequestId} request will have the status as "approved"
{
"certRequestId": 549,
"moduleId": 190,
"status": "approved",
"validationCertificate": "AMV-10",
"amvVersion": "0.1"
}Error Responses#
In the event of an unexpected error occurring within the protocol, the AMVP server MUST respond with to AMVP client requests with a JSON encoded message following the format below.
{
"amvVersion": "{amvp-version}",
"category": 0,
"description": "{description of category}",
"errors": [
{
"code": 1,
"messages": ["First message", "Second message", "..."]
},
{
"code": 2,
"messages": ["First message", "Second message", "..."]
},
]
}The integer value for "category" MUST match a category code defined in table 1 below.
Individual error codes are defined in each section of the specification. Codes that are used between different sections should still appear in each section. If an error occurs that is not defined in the specification, the AMVP server MUST use an error code of 0. If multiple error codes exist that could describe a given error, the AMVP server SHALL use the one most specific to that situation.
An error response from the AMVP server MUST have at least a single error object within the "errors" array. The AMVP server also SHALL include at least one message for each error object, and SHOULD include as many messages as are relevant to each object. The AMVP server MAY also add additional key/value pairs to each error object depending on the implementation, but any added key/value pairs MUST be relevant to describing or troubleshooting the error. For the sake of consistency, the AMVP server MUST NOT include errors from different categories of errors in a single response.
| Category Code | Description String | HTTP[S] Code | Protocol Description |
|---|---|---|---|
0 |
"General or Undefined Error" |
For errors that do not fit into another category |
|
1 |
"Authentication and/or Authorization Error" |
403 |
For errors caused by an AMVP client having insufficient credentials to access the requested endpoint or resource |
2 |
"Malformed Payload Error" |
400 |
For errors caused by syntactically incorrect requests. Possible examples include invalid JSON or invalid HTTP[S] request headers |
3 |
"Invalid Data or Request Error" |
422 |
For errors caused by requests that are properly formatted but semantically incorrect. This includes errors related to a client sending data that is invalid within the bounds of the protocol; for example, out of bounds registration values |
4 |
"Server Error" |
For unexpected errors generated by server logic or outages |
Other sections of the specification may define required HTTP[S] codes for specific scenarios that do not have one defined in table 1. If an HTTP[S] code is not specified for a given error or category of errors, the AMVP server SHOULD use an HTTP[S] code that is most relevant to the error being returned to the AMVP client. While AMVP clients MAY use HTTP[S] codes to determine the general status of a request, AMVP clients SHOULD NOT depend on HTTP[S] codes for differentiating between types of errors; instead, they should rely on the contents of the response body described above.
Examples#
Flow based on TE Summary
Login to obtain accessToken
+--------+--------------------------------------+------+------------+
| Client | |Server| Notes |
+--------+--------------------------------------+------+------------+
| |POST to /login or similar with | | |
| |appropriate credentials | | |
| |--------------------------------> | | |
| | | | |
| |200 OK receive the access token | | |
| |<- - - - - - - - - - - | | |
| | | | |
POST: {"amvVersion": "0.1", "passcode":"21887897"}
200 OK: {"accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....}
POST certRequests - request a module validation certificate
+--------+-----------------------------------+------+------------+
| Client | |Server| Notes |
+--------+-----------------------------------+------+------------+
| |POST certRequests | | Submit |
| |---------------------------------->| |Module Cert |
| | w/URIs to bind modules, vendors, | | Request |
| | and contacts | | |
| | | | |
| |200 OK | | Returns |
| |<- - - - - - - - - - - -| | CR ID |
| | "url": "/amvp/v1/certRequests/550"| | |
| | "vendorId": 137, | | |
| | "status": "initial", | | |
| | "accessToken": "" | | |
| | | | |
| | | | |
| |GET | | |
| |/certRequests/1 | | Retrieve |
| |---------------------------------->| | CR ID |
| | | | TE List |
| |200 OK with List of TEs, moduleId | | |
| |<- - - - - - - - - - - -| | |
| | | | |
| |POST Test Evidence | | |
| |/certRequests/1/evidence | | Submit |
| |---------------------------------->| | Response |
| | | | |
| |200 OK | | |
| |<- - - - - - - - - - - -| | |
| | vendorId : 1 | | |
| | status: processing | | |
| |GET | | |
| |/certRequests/1 | | GET |
| |---------------------------------->| | Results |
| | | | |
| |<----------------------------------| | |
| | 200 OK "status": "submitted" | | |
| | "Url": | | |
| | "/amvp/v1/certRequests/41763" | | |
The binding will look something like this:
[{ "moduleId" : 121, <-- a single module
"vendorId" : 12345, <-- vendor ID from resource submission not shown above
"testers" : ["CVP-0-000001", "CVP-0-000002"] <-- CVP numbers represent people that have lab accreditation
}]
The Functional Test TE list sent from client to server will look like this
{
"amvVersion": "0.1",
"functionalTest":
{
"document":
{
"base-catalogVersion": "3.0",
"base-lastUpdated": "October-16-2023",
"functionalTesting-EC": "0.6",
"functionalTesting-lastUpdated": "October-29-2024"
},
"testEvidence":
[
{
"teList":
[
"TE02.12.01","TE02.10.01"
],
"description": "Verify that versioning info identifies distinct components.",
"access": "physical",
"technique": "debugger simulation emulation harness manual other",
"setup": "reference into Catalog",
"errorInduction": "description of",
"results":
{
"summary": "sample summary",
"digest": "000000",
"fileLocation": "location of test evidence",
"integrityMechanism": "SHA2-512"
}
}
]
}
}
The Source Code evidence sent from client to server will look like this
{
"amvVersion": "0.1",
"sourceCode": {
"document": {
"base-catalogVersion": "3.0",
"base-lastUpdated": "October-16-2023",
"sourceCode-EC": "0.6",
"sourceCode-lastUpdated": "October-29-2024"
},
"testEvidence": [
{
"teList": [
"TE02.10.01",
"TE02.07.01",
"TE02.07.02"
],
"file": [
"full path to file"
],
"function": "Source code method/function(s)",
"lines": "Source code line numbers",
"description": "Summarize how the source code review aspect of the TE was accomplished.",
"input": "may not always be applicable",
"output": "may not always be applicable",
"status": "",
"results":
{
"summary": "sample summary",
"digest": "000000",
"fileLocation": "location of test evidence",
"integrityMechanism": "SHA2-512"
}
}
]
}
}
The Other Documentation evidence sent from client to server will look like this
{
"amvVersion": "0.1",
"otherDocumentation": {
"document": {
"base-catalogVersion": "3.0",
"base-lastUpdated": "October-16-2023",
"otherDocumentation-EC": "0.6",
"otherDocumentation-lastUpdated": "October-29-2024"
},
"testEvidence": [
{
"teList": [
"TE02.03.02"
],
"documents":
[
{
"sectionName": "sample",
"documentName": "sampleDocument"
}
],
"results":
{
"summary": "sample summary",
"digest": "000000",
"fileLocation": "location of test evidence",
"integrityMechanism": "SHA2-512"
}
}
]
}
}
The Security Policy sent from client to server will look like this
{
"amvVersion": "0.1",
"securityPolicy": {
"schemaVersion": "2.8.4",
"cavpCertSet": {
"cavpCertList": [
{
"vendorName": "Duis ea",
"certName": "in sed nulla do dolor",
"validationId": 11023992,
"implName": "exercitation tempor ad",
"implVersion": "ut sed cillum",
"implType": "esse est ea quis cillum",
"implOrganization": "magna ipsum aliqua proident sit"
}
],
"cavpOeList": [
{
"name": "consectetur do cupidatat Ut",
"oeId": 3
}
],
"cavpOeAlgoList": [
{
"validationOeAlgorithmId": 1,
"algoDisplayName": "exercitation ad",
"canonicalAlgorithmId": 1,
"validationId": 1,
"certName": "anim fugiat nisi Lorem enim",
"implName": "velit exercitation irure magna eu",
"oeId": 8308,
"selectedCapList": [
{
"capabilityId": 31642322,
"displayText": "esse",
"childCapabilities": []
}
]
}
],
"cavpImplAlgoList": [
{
"algoDisplayName": "AES-CBC",
"canonicalAlgorithmId": 1,
"implName": "in Lorem",
"validationId": 7,
"certName": "nisi ex sint",
"category": "laboris velit"
}
],
"cavpItarAlgoList": [
{
"certName": "elit esse est",
"algoDisplayName": "AES-CBC-CS3",
"canonicalAlgorithmId": 4,
"capabilities": "deserunt est sed ad eiusmod",
"category": "Duis mollit magna"
}
]
},
"esvCertList": [
{
"esvCertName": "laboris veniam sunt dolore reprehenderit",
"certId": 33293608,
"vendorName": "cupidatat sit amet sunt"
}
],
"esvItarCertList": [
"pariatur",
"Lorem"
],
"testedHwList": [
{
"modelPartNum": "sint aute cillum quis",
"hwVersion": "et cupidatat",
"fwVersion": "consequat",
"processors": "consequat",
"features": "laborum id exercitation laboris veniam"
}
],
"testedSwFwHyList": [
{
"packageFileName": "laborum commodo consectetur nulla",
"swFwVersion": "magna",
"features": "anim Ut dolor occaecat in",
"integrityTest": "consequat ipsum dolor elit"
}
],
"testedHyHwList": [
{
"modelPartNum": "quis ullamco",
"hwVersion": "nisi laboris",
"fwVersion": "aliquip Lorem est in tempor",
"processors": "mollit sunt",
"features": "cupidatat"
}
],
"opEnvSwFwHyTestedList": [
{
"operatingSystem": "nostrud aliquip proident",
"hardwarePlatform": "in ut enim quis irure",
"processors": "nulla cupidatat",
"paaPai": "esse",
"hypervisorHostOs": "Excepteur ipsum labore elit",
"swFwVersionList": [
"deserunt est consequat pariatur ex",
"tempor dolor eiusmod",
"ipsum dolor",
"Ut cupidatat",
"et consequat"
]
}
],
"opEnvSwFwHyVAList": [
{
"operatingSystem": "reprehenderit culpa ut",
"hardwarePlatform": "pariatur esse in consectetur"
}
],
"modeOfOpList": [
{
"name": "officia commodo",
"description": "in ipsum",
"type": "aliquip",
"statusIndicator": "laborum"
}
],
"vendorAffirmedAlgoList": [
{
"name": "in ad in",
"algoPropList": [
{
"name": "id velit anim Ut veniam",
"value": "enim voluptate",
"propertyId": 11387443
}
],
"implName": "sed Excepteur",
"reference": "ullamco culpa"
}
],
"nonApprovedAllowedAlgoList": [
{
"name": "deserunt laboris non",
"algoPropList": [
{
"name": "ea aute consectetur Duis",
"value": "in ut",
"propertyId": -57056207
}
],
"implName": "incididunt enim anim",
"reference": "consectetur"
}
],
"nonApprovedAllowedAlgoNSCList": [
{
"name": "quis in",
"caveat": "ut adipisicing",
"useFunction": "non eu"
}
],
"nonApprovedNotAllowedAlgoList": [
{
"name": "in Ut incididunt",
"useFunction": "irure"
}
],
"secFunImplList": [
{
"name": "nostrud ex",
"sfTypeList": [
{
"sfAbbrev": "ad Excepteur sed id",
"sfId": 53184293
}
],
"description": "ad quis irure nisi",
"sfPropList": [
{
"name": "non veniam sint tempor occaecat",
"value": "et",
"propertyId": -30179093
}
],
"algorithmList": [
{
"algoDisplayName": "magna cupidatat laborum Ut in",
"canonicalAlgorithmId": 47899832,
"implName": "velit laborum sint id nostrud",
"validationId": 5,
"algoPropList": [],
"certName": "et"
}
]
}
],
"entropySourceList": [
{
"name": "labore ex",
"type": "reprehenderit",
"opEnv": "eu est",
"sampleSize": "exercitation",
"entropyPerSample": "cillum laborum",
"conditioningComp": "fugiat"
}
],
"portInterfaceList": [
{
"physicalPort": "ullamco",
"logicalInterfaceList": [
"ex qui velit eu",
"est",
"Duis sit labore aute ex",
"laborum fugiat adipisicing"
],
"dataPasses": "ullamco voluptate in ut veniam"
}
],
"authMethodList": [
{
"name": "labore exercitation dolore do dolore",
"description": "deserunt non ut",
"mechanism": "nostrud culpa",
"strengthEachAttempt": "exercitation reprehenderit dolor sed cillum",
"strengthPerMin": "deserunt"
}
],
"roleList": [
{
"name": "aliquip fugiat",
"type": "sint ut dolore Duis veniam",
"operatorType": "ea elit aliquip officia",
"authMethodList": [
"adipisicing Ut in",
"velit cillum cupidatat consectetur",
"labore adipisicing",
"Ut"
]
}
],
"approvedServiceList": [
{
"name": "ut",
"description": "labore eu irure",
"indicator": "qui",
"inputs": "ea cupidatat ullamco pariatur irure",
"outputs": "Ut aute",
"secFunImplList": [
"in",
"minim sed",
"ad pariatur"
],
"roleSspAccessList": [
{
"roleName": "aute esse do laborum",
"sspAccessList": [
{
"sspName": "quis consequat tempor laboris reprehenderit",
"accessType": [
"veniam laborum tempor",
"cupidatat aute",
"ut esse sint Lorem",
"culpa nulla",
"sit consequat incididunt occaecat"
]
}
]
},
{
"roleName": "incididunt id adipisicing et",
"sspAccessList": [
{
"sspName": "amet esse",
"accessType": [
"sunt dolore mollit",
"ipsum incididunt nisi in"
]
}
]
},
{
"roleName": "non Lorem est incididunt sit",
"sspAccessList": [
{
"sspName": "reprehenderit pariatur nisi sed",
"accessType": [
"consequat",
"amet"
]
}
]
},
{
"roleName": "non enim proident ex",
"sspAccessList": [
{
"sspName": "dolor voluptate",
"accessType": [
"aliquip esse",
"et laborum eiusmod veniam"
]
}
]
},
{
"roleName": "elit",
"sspAccessList": [
{
"sspName": "do sit dolor",
"accessType": [
"veniam ad do",
"irure"
]
}
]
}
]
}
],
"nonApprovedServiceList": [
{
"name": "anim quis elit",
"description": "commodo et deserunt",
"nonApprovedAlgoList": [
"nisi ea incididunt deserunt",
"Duis cillum",
"voluptate elit aute in",
"veniam"
],
"role": "exercitation aliquip"
}
],
"phSecMechanismList": [
{
"mechanism": "sunt",
"inspectFreq": "quis cupidatat in",
"inspectGuidance": "ullamco nulla in commodo sit"
}
],
"efpEftInfoList": [
{
"tempVoltType": "ullamco non",
"tempVolt": "non irure consectetur mollit",
"efpOrEft": "consectetur",
"result": "ad"
}
],
"hardnessTestTempList": [
{
"tempType": "aute veniam",
"temp": "culpa in"
}
],
"storageAreaList": [
{
"name": "sit exercitation nostrud veniam",
"description": "aliquip amet dolor deserunt Lorem",
"persistenceType": "sit consectetur ad ipsum irure"
}
],
"sspInputOutputList": [
{
"name": "aliquip do",
"from": "eu sint amet Duis Excepteur",
"to": "Excepteur commodo",
"formatType": "magna",
"distributionType": "dolor ea nostrud laboris ut",
"entryType": "officia voluptate ipsum adipisicing",
"relatedSFI": "non irure"
}
],
"sspZeroizationList": [
{
"method": "sint in",
"description": "veniam",
"rationale": "nostrud",
"operatorInitiation": "culpa cillum proident"
}
],
"sspList": [
{
"name": "nulla",
"description": "in non minim",
"size": "id",
"strength": "Lorem consequat sunt mollit",
"type": "id",
"generatedByList": [
"est",
"mollit in dolor eu Duis",
"irure exercitation est commodo",
"anim eu aliqua Excepteur",
"ullamco ad mollit"
],
"establishedByList": [
"anim eiusmod",
"sed enim tempor",
"officia cillum ex nostrud",
"elit voluptate amet laborum labore",
"Duis amet culpa"
],
"usedByList": [
"quis",
"proident",
"adipisicing ea mollit",
"cupidatat nisi incididunt dolore",
"voluptate tempor"
],
"inputOutputList": [
"aliqua ut nisi consequat",
"nulla in cillum est"
],
"storageItemList": [
{
"areaName": "est consequat dolore",
"format": "in",
"algorithmName": "ad"
}
],
"storageDuration": "nostrud",
"zeroizationList": [
"ad nostrud occaecat",
"minim ad incididunt irure",
"aute eiusmod"
],
"category": "elit do aliquip",
"relatedSspList": [
{
"sspName": "quis laborum qui",
"relationship": "mollit laborum nostrud in ut"
}
]
}
],
"preOpSelfTestList": [
{
"algorithmOrTest": "reprehenderit exercitation commodo velit",
"testProps": "ullamco nostrud",
"testMethod": "amet sit minim",
"type": "veniam",
"indicator": "ut irure pariatur adipisicing",
"details": "labore voluptate nisi",
"period": "in eu ex",
"periodicMethod": "in eu officia minim"
}
],
"condSelfTestList": [
{
"algorithmOrTest": "sed laboris Ut",
"testProps": "culpa",
"testMethod": "ea",
"type": "laborum dolore tempor nisi",
"indicator": "sit sed cillum qui",
"details": "enim adipisicing eu cupidatat amet",
"conditions": "amet laboris",
"coverage": [],
"coverageNotes": "velit culpa officia",
"period": "sit",
"periodicMethod": "dolor reprehenderit Duis"
}
],
"errorStateList": [
{
"name": "velit in",
"description": "ex",
"conditions": [
"reprehenderit nostrud cillum anim labore",
"do dolor officia",
"adipisicing voluptate do tempor"
],
"recoveryMethod": "aliquip",
"indicator": "irure amet"
}
],
"referenceList": [
"do occaecat sunt",
"irure velit"
]
}
}
[AMVP]: POST Response Submission…
{
"url": "/amvp/v1/certRequests/8",
"moduleId": 2,
"vendorId": 1,
"status": "ready",
"securityPolicyStatus": "acceptingSubmissions",
"evidenceStatus": "acceptingSubmissions",
"missingSPTemplate": true,
"missingSecurityPolicySubmission": true,
"evidenceList": [
{
"te": "TE02.10.01",
"required": [],
"oneOf": [
{
"types": [
"SC-TE",
"FT-TE"
],
"submitted": []
}
],
"complete": false
},
{
"te": "TE02.12.01",
"required": [
{
"types": [
"FT-TE"
],
"submitted": []
}
],
"oneOf": [],
"complete": false
},
{
"te": "TE02.19.02",
"required": [
{
"types": [
"FT-TE"
],
"submitted": []
}
],
"oneOf": [],
"complete": false
},
{
"te": "TE02.22.02",
"required": [
{
"types": [
"FT-TE"
],
"submitted": []
}
],
"oneOf": [],
"complete": false
},
],
"amvVersion": "0.1"
}
Once the validation is approved the functionalTest evidence, source code evidence, and security policy, draft certificate can be requested.
| |GET | | | | |/certRequests/1/securityPolicy | | Retrieve | | |---------------------------------->| |Sec Policy | | | | | ID = 1 | | |<--------------------------------- | | Retry as | | | | | needed | | | | | | | |GET | | | | |/certRequests/1/securityPolicy | | Retrieve | | |---------------------------------->| |Sec Policy | | | | | | | | | | | | |200 OK | | | | |<- - - - - - - - - - - -| | | | | Security Policy | | |
Module certificate is fully approved.
| |POST | | | | |/certRequests/1/certify | | Request | | |---------------------------------->| | | | | | | ID = 1 | | |<--------------------------------- | | Retry as | | | | | needed | | | | | | | |GET | | | | |/certRequests/1 | | Retrieve | | |---------------------------------->| | cert status| | | | | | | | | | | | |200 OK | | | | |<- - - - - - - - - - - -| | | | | Certificate request status | | |
[AMVP]: GET Response
{
"certRequestId": 549,
"moduleId": 190,
"status": "approved",
"validationCertificate": "AMV-10",
"amvVersion": "0.1"
}
Proof of Concept Flows(outdated, remaining here for reference)
The initial Proof of Concept(PoC) developed will be limited to communication flows that are needed to demo the protocol. Separate auotmated and non-automated evidence will not be included in the PoC. These flows can also be used to define the exact testing that will be required for the various server and client milestones. Some milestones are server centric thus testing is limited here since minimal external communication flows are exercised. Error codes and retries will be tested when possible in all test flows.
V0.1 Test Flows
Prerequiste for V0.1 testing is VPN between client and server, TOTP and client certificate.
Workflow authorization flows.
+--------+--------------------------------------+------+------------+
| Client | |Server| Notes |
+--------+--------------------------------------+------+------------+
| |POST to /login or similar with | | |
| |appropriate credentials | | |
| |--------------------------------> | | |
| | | | |
| |200 OK receive the access token | | |
| |<- - - - - - - - - - - | | |
| | | | |
| |POST /amvp/v1/vendors | | POST |
| |----------------------------------> | | vendor | *** vendor resource as an example
| | | | resource | *** flow is to show login sequence
| | | | |
| | | | |
| |200 OK vendors URI | | |
POST: [{"passcode":"21887897"}]
200 OK: [{"accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....}]
Vendor POST prior to login(should fail) and after login(should be accepted). Server shall respond to valid vendor POST with 200 OK.
Expected Client Log(failing case)
[AMVP]: POST...
Status: 404
Url: https://localhost:8085/amvp/v1/vendors
Resp: The path specified is not recognized.
[AMVP][ERROR]: 404 error received from server. Message:
[AMVP][ERROR]: The path specified is not recognized.
Expected Client Log(successful case)
[AMVP]: Logging in...
[AMVP]: Login info: [{"passcode":"21887897"}]
[AMVP]: POST Login...
Status: 200
Url: https://localhost:8085/amvp/v1/login
Resp: [{ "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...."}]
[AMVP]: Login successful
[AMVP]: POST...
Status: 200
Url: https://localhost:8085/amvp/v1/vendors
JWT Expiration/Renewal
The JWT access tokens received from either the /login server endpoint SHALL be set to expire after a pre-defined period. The specific length of the expiration period is out of scope for this specification. However, the expiration period length impacts both the security and protocol overhead. Longer expiration periods reduce the overhead but increase the window for attacks. Attempting to access a service with an expired JWT SHALL result in a "401 Unauthorized" HTTP status code.
A client may renew an expired JWT access token using the mechanism shown in [xml_figureRenewalFlows]below.
JWT access token renewal flows. All exchanges shown are over HTTP.
+--------+---------------------------------+------+--------+
| Client | |Server| Notes |
+--------+---------------------------------+------+--------+
| |POST to /login or similar with | | |
| |appropriate credentials | | |
| |and expired JWT access token | | |
| |-------------------------------->| |session |
| | | |or |
| | | |login |
| | | |JWT |
| |receive the renewed access token | | |
| |<- - - - - - - - - - - | | |
| | | | |
JWT authorization has timed out, curl rc=401
POST: [{"passcode":"47682787","accessToken":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....}]
200 OK: [{"accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.....}]
Log
[AMVP]: Logging in...
[AMVP]: Login info: [{"passcode":"63127656"}]
[AMVP]: POST Login...
Status: 200
Url: https://localhost:8085/amvp/v1/login
Resp: [{ "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...."}]
[AMVP]: Login successful
[AMVP]: POST Data: /amvp/v1/vendors
[AMVP][WARNING]: JWT authorization has timed out, curl rc=401. Refreshing session...
[AMVP]: Logging in...
[AMVP]: Login info: [{"passcode":"12345678","accessToken":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...."}]
[AMVP]: POST Login...
Status: 200
Url: https://localhost:8085/amvp/v1/login
Resp: [{ "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...."}]
[AMVP]: Login successful
[AMVP]: Refresh successful, attempting to continue...
[AMVP]: POST...
Status: 200
Url: https://localhost:8085/amvp/v1/vendors
V0.2 Test Flows
Metadata creation and update example. The list of available reseource metadata endpoints can be found in [xml_uriResources]. An example minimum message flow between client and server after receiving the JWT is seen in the figure below.
Test vendors, modules and evidence catalog.
+--------+-----------------------------------+------+------------+
| Client | |Server| Notes |
+--------+-----------------------------------+------+------------+
| |POST /amvp/v1/modules | | Create |
| |---------------------------------->| | Metadata |
| | | | |
| |receive request identifier | | |
| |<- - - - - - - - - - - -| | |
| | | | |
| |PUT /modules | | Update |
| |---------------------------------->| | Metadata |
| | | | |
| |receive request identifier | | |
| |<- - - - - - - - - - - -| | |
| | | | |
Log
[AMVP]: Logging in...
[AMVP]: Login info: [{"passcode":"37362840"}]
[AMVP]: POST Login...
Status: 200
Url: https://localhost:8085/amvp/v1/login
Resp: [{ "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}]
[AMVP]: Login successful
[AMVP]: POST...
Status: 200
Url: https://localhost:8085/amvp/v1/modules
Resp: [{ "url": "/amvp/v1/requests/28665", "status": "approved", "approvedUrl": "/amvp/v1/modules/13780" }] ** Immediate approval or just 200 OK ?
V0.3 Test Flows
Re-test V0.1 and V0.2 verify server creates objects. Use GET for resource objects and evidence.
After re-running V0.2 perform GET on objects following POST.
| |GET | | |
| |/requests/1 | | Retrieve |
| |---------------------------------->| | Request |
| | | | |
| |receive module URL | | |
| |<- - - - - - - - - - - -| | |
| | /amvp/v1/modules/11208 | | |
| | | | |
After re-running V0.2 perform GET on objects following PUT.
| |GET | | |
| |/requests/2 | | Retrieve |
| |---------------------------------->| | Request |
| | | | |
| |module URL: | | updated |
| |<- - - - - - - - - - - -| | or new |
| | /amvp/v1/modules/11208 | | |
| | | | |
GET after POST or PUT log
[AMVP]: Logging in...
[AMVP]: Login info: [{"passcode":"25008415"}]
[AMVP]: POST Login...
Status: 200
Url: https://localhost:8085/amvp/v1/login
Resp: [{ "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...."}]
[AMVP]: Login successful
[AMVP]: GET...
Status: 200
Url: https://localhost:8085/amvp/v1/modules/13780
Resp: [{
{
"schemaVersion": "initial",
"moduleInfo": {
"name": "OpenSSL FIPS Provider",
"count": 1,
"description": "FIPS Provider V3.0.0",
"embodiment": "Single Chip",
"type": "software",
"opEnvType": "Intel X86_64",
"submissionLevel": "Level 1",
"itar": false,
"overallSecurityLevel": 1
},
"secLevels": [
{
"section": 1,
"level": 1
},
{
"section": 2,
"level": 1
},
{
"section": 3,
"level": 1
},
{
"section": 4,
"level": 1
},
{
"section": 5,
"level": 1
},
{
"section": 6,
"level": 1
},
{
"section": 7,
"level": 1
},
{
"section": 8,
"level": 1
},
{
"section": 9,
"level": 1
},
{
"section": 10,
"level": 1
},
{
"section": 11,
"level": 1
},
{
"section": 12,
"level": 1
}
],
"implementsOtar": true,
"hasNonApprovedMode": true,
"requiresInitialization": true,
"hasExcludedComponents": true,
"hasDegradedMode": false,
"hasPPAorPAI": false,
"hasEmbeddedOrBoundModule": false,
"hasCriticalFunctions": false,
"hasNonApprovedAlgorithmsInApprovedMode": false,
"hasExternalInputDevice": false,
"hasExternalOutputDevice": false,
"usesTrustedChannel": true,
"supportsConcurrentOperators": true,
"usesIdentityBasedAuthentication": true,
"hasMaintenanceRole": true,
"allowsOperatorToChangeRoles": false,
"hasDefaultAuthenticationData": true,
"usesEDC": true,
"allowsExternalLoadingOfSoftwareOrFirmware": false,
"containsNonReconfigurableMemory": true,
"usesOpenSource": false,
"providesMaintenanceAccessInterface": false,
"hasVentilationOrSlits": false,
"hasRemovableCover": false,
"hasTamperSeals": false,
"hasOperatorAppliedTamperSeals": false,
"hasEFPorEFT": false,
"outputsSensitiveDataAsPlaintext": false,
"supportsManualSSPEntry": true,
"usesSplitKnowledge": true,
"hasCVE": true,
"hasAdditionalMitigations": false,
"usesOtherCurve": true,
"supportsBypassCapability": false,
"hasOTPMemory": false
}
V0.4 Test Flows
Submit evidence to server and return results.
+--------+-----------------------------------+------+------------+
| Client | |Server| Notes |
+--------+-----------------------------------+------+------------+
| |POST certRequests | | Submit |
| |---------------------------------->| |Module Cert |
| | w/URIs to bind modules, vendors, | | Request |
| | and contacts | | |
| | | | |
| |200 OK certRequests URLs | | |
| |<- - - - - - - - - - - -| | |
| | certRequests/1/evidence | | |
| | | | |
| |GET (automatable evidence) | | |
| |/certRequests/1/evidence | | Retrieve | ** GET supported in V0.5 ?
| |---------------------------------->| |Cert Request|
| | | | assertions |
| |200 OK assertions for evidence 1 | | |
| |<- - - - - - - - - - - -| | |
| | | | |
| |POST Test Evidence for assertions | | |
| |for automatable evidence | | Submit |
| |---------------------------------->| | Response |
| | | | |
| |200 OK | | |
| |<- - - - - - - - - - - -| | |
| | state: autoInReview | | |
| | | | |
Log
[AMVP]: Logging in...
[AMVP]: Login info: [{"passcode":"33222621"}]
[AMVP]: POST Login...
Status: 200
Url: https://localhost:8085/amvp/v1/login
Resp: [{ "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...."}]
[AMVP]: Login successful
[AMVP]: Reading module cert request file...
[AMVP]: Sending module cert request...
[AMVP]: POST...
Status: 200
Url: https://localhost:8085/amvp/v1/certRequests
{
"moduleId" : 121,
"vendorId" : 12345,
"contacts" : ["CVP-012345", "CVP-67890"]
}
Resp: [{ "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....",
"url": "/amvp/v1/certRequests/287357", "crUrls": [ "/amvp/v1/certRequests/287357/evidence/1146094" ]}]
[AMVP]: Successfully sent mod cert req and received list of TE URLs
[AMVP]: GET /amvp/v1/certRequests/287357/evidence/1146094
[AMVP]: GET Vector Set...
Status: 200
Url: https://localhost:8085/amvp/v1/certRequests/287357/evidence/1146094
Resp:
[{ "evidenceId": 1146094, "revision": "1.0", "teGroups": [ { "teId": 1, "autoTE": ["TE02.20.01", "TE02.20.02", "TE11.16.01","TE04.11.01", "TE04.11.02"]}]}]
[AMVP]: Processing ie set: 1146094
[AMVP]: Successfully processed vector set
[AMVP]: Posting ie set responses for vsId 1146094 to URL: /amvp/v1/certRequests/287357/evidence/1146094...
[AMVP]: POST Response Submission...
Status: 200
Url: https://localhost:8085/amvp/v1/certRequests/287357/evidence/1146094/results
V0.5 Test Flows
Server will complete processing of evidence and return status.
+--------+-----------------------------------+------+------------+
| Client | |Server| Notes |
+--------+-----------------------------------+------+------------+
| |POST certRequests | | Submit |
| |---------------------------------->| |Module Cert |
| | w/URIs to bind modules, vendors, | | Request |
| | and contacts | | |
| | | | |
| |200 OK certRequests URLs | | |
| |<- - - - - - - - - - - -| | |
| | state: IUT | | |
| | certRequests/1/evidence/1 | | |
| | | | |
| |GET | | |
| |/certRequests/1/evidence/1 | | Retrieve |
| |---------------------------------->| |Cert Request|
| | | | assertions |
| |200 OK assertions for evidence 1 | | |
| |<- - - - - - - - - - - -| | |
| | | | |
| |POST Test Evidence for assertions | | Submit |
| |---------------------------------->| | Response |
| | | | |
| |200 OK | | |
| |<- - - - - - - - - - - -| | |
| | state: autoInReview | | |
| | | | |
| |GET | | |
| |certRequests/1/results | | Retrieve |
| |---------------------------------->| |Disposition |
| | | | |
| |200 OK receive results | | |
| |<- - - - - - - - - - - -| | |
| | state: autoInReview | | |
--- Poll periodically ---
| |GET | | |
| |certRequests/1/results | | Retrieve |
| |---------------------------------->| |Disposition |
| | | | |
| |200 OK receive results | | |
| |<- - - - - - - - - - - -| | |
| | state: autoCoordination | | |
| | "passed": true | | |
| | | | |
| | PUT | | |
| | certRequests/1/evidence/1 | | |
| |---------------------------------->| | |
| | | | |
| |200 OK receive results | | |
| |<- - - - - - - - - - - -| | |
| | state: autoCoordination | | |
| | "url": "/amvp/v1/requests/1", | | |
| | "status": "initial"} | | |
| | | | |
| |GET | | |
| |certRequests/1/results | | Retrieve |
| |---------------------------------->| |Disposition |
| | | | |
| |200 OK receive results | | |
| |<- - - - - - - - - - - -| | |
| | state: pendingAudit | | |
| | "url" : "/amvp/v1/requests/1" | | |
| | | | |
| |GET | | |
| |/requests/1 | | |
| |---------------------------------->| | Retrieve |
| | | | Request |
| |200 OK receive cert | | |
| |<- - - - - - - - - - - -| | |
| | state: finalization | | Complete |
| | "approvedUrl" : "/amvp/v1/validations/1",
| | “modValidationId": "M1"
Optional Flow:
Independently GET docs as needed
| |GET | | |
| |certRequests/1/docs | | Retrieve |
| |---------------------------------->| | Docs |
| | | | |
--- Poll periodically ---
| |200 OK receive results | | |
| |<- - - - - - - - - - - -| | Doc URLs |
| |"secPolicy" : "/amvp/v1/sp0001" | | |
| |"draftCert" : "/amvp/v1/dc0001" | | |
| | | | |
[AMVP]: Logging in...
[AMVP]: Login info: [{"passcode":"03363978"}]
[AMVP]: POST Login...
Status: 200
Url: https://localhost:8085/amvp/v1/login
Resp: [{ "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...."}]
[AMVP]: Login successful
[AMVP]: Reading module cert request file...
[AMVP]: Sending module cert request...
[AMVP]: POST...
Status: 200
Url: https://localhost:8085/amvp/v1/certRequest
POST /amvp/v1/certRequests/1
[{"moduleId" : [{"/amvp/v1/modules/0918273546"}]
},{ "vendorId" : {"/amvp/v1/vendors/12345"}
}, { "contacts" : [{"John Smith", {"CVP" : "012345"}}, {"Jane Smith", {"CVP" : "67890"}}]
}]
Resp: [{ "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...."},
"url": "/amvp/v1/certRequests/287357", "crUrls": [ "/amvp/v1/certRequests/287357/evidence/1146094" ]}]
[AMVP]: Successfully sent mod cert req and received list of TE URLs
[AMVP]: GET /amvp/v1/certRequests/287357/evidence/1146094
[AMVP]: GET Vector Set...
Status: 200
Url: https://localhost:8085/amvp/v1/certRequests/287357/evidence/1146094
Resp:
[{ "evidenceId": 1146094, "revision": "1.0", "teGroups": [ { "teId": 1, "autoTE": ["TE02.20.01", "TE02.20.02", "TE11.16.01","TE04.11.01", "TE04.11.02"]}]}]
[AMVP]: Processing ie set: 1146094
[AMVP]: Successfully processed vector set
[AMVP]: Posting ie set responses for vsId 1146094 to URL: /amvp/v1/certRequests/287357/evidence/1146094...
[AMVP]: POST Response Submission...
{
"evidenceSet": [
{
"testRequirement": "TE02.20.01",
"evidence": "\/acvp\/v1\/validations\/99999",
"note": "this is a fake endpoint"
},
{
"testRequirement": "TE02.20.02",
"evidence": "none"
},
{
"testRequirement": "TE11.16.01",
"evidence": "Version X.Y.Z of the module meets the assertion"
},
{
"testRequirement": "TE04.11.01",
"evidence": "<BASE64(table of services.pdf) compliant with SP 800-140Br>"
},
{
"testRequirement": "TE04.11.02",
"evidence": "\/www.cisco.com\/amvpevidence\/log_te041102.txt",
"note": "this is a fake endpoint"
},
{
"testRequirement": "TE10.10.01",
"evidence": "Degraded mode not supported, no algorithms can be used...goes directly into SP."
},
{
"testRequirement": "TE10.10.02",
"evidence": "\/www.cisco.com\/amvpevidence\/log_te041102.txt",
"note": "this is a fake endpoint"
},
{
"testRequirement": "TE11.08.01",
"evidence": "\/www.cisco.com\/amvpevidence\/FSM.pdf",
"note": "this is a fake endpoint"
},
{
"testRequirement": "TE11.08.02",
"evidence": "See TE11.08.01"
}
]
}
Status: 200
Url: https://localhost:8085/amvp/v1/certRequests/287357/evidence/1146094/results
[AMVP]: GET Vector Set Result...
Status: 200
Url: https://localhost:8085/amvp/v1/certRequests/287357/results
Resp:
[ { "passed": true, "results": [ { "evSetUrl": "/amvp/v1/certRequests/287357/evidence/1146094", "status": "passed" }]} ]
[AMVP]: Passed all evidence in test session!
--optional--
[AMVP]: Tests complete, request SP and DC...
[AMVP]: GET SP and DC...
Status: 200
Url: https://localhost:8085/amvp/v1/certRequests/287357/docs
Resp:
[ {"secPolicyUrl" : "/amvp/v1/requests/287355", "draftCertUrl" : "/amvp/v1/requests/287356"}]
[AMVP]: Security Policy url: /amvp/v1/requests/287355
[AMVP]: Draft Certificate url: /amvp/v1/requests/287356
[AMVP]: PUT testSession Validation...
Status: 200
Url: https://localhost:8085/amvp/v1/certRequests/287357
{"moduleUrl": "/amvp/v1/modules/11630}
Resp: [ { "url": "/amvp/v1/requests/27358", "status": "initial"}]
[AMVP]: Validation requested -- status initial -- url: /amvp/v1/requests/27358
Once audit completed, GET request approval.
[AMVP]: Logging in...
[AMVP]: Login info: [{"passcode":"85380204"}]
[AMVP]: POST Login...
Status: 200
Url: https://localhost:8085/amvp/v1/login
Resp: [{ "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...."}]
[AMVP]: Login successful
[AMVP]: GET Response:
[ { "url": "/amvp/v1/requests/27358", "status": "approved", "approvedUrl": "/amvp/v1/validations/41763"}]
V1.0 Test Flows
Full flow support through validation completion.
JSON for UT
Lab
Vendor
POSTed to /amvp/v1/vendors
{
"vendor": {
"name": "Cisco Systems, Inc.",
"addresses": [
{
"street": "170 West Tasman Dr.",
"locality": "San Jose",
"region": "CA",
"country": "USA",
"postalCode": "95134"
}
],
"website": "www.cisco.com",
"productLink": "www.cisco.com/product/cr9000",
"contacts": [
{
"name": "Tom Smith",
"phoneNumbers": [
"123-456-7890"
],
"emails": [
"[email protected]"
]
}
]
}
}
ModuleSpec
POSTed to /amvp/v1/modules