Iteration 5 » Historie » Revize 6
Revize 5 (Jan Pašek, 2021-04-22 15:33) → Revize 6/7 (Jan Pašek, 2021-04-22 15:40)
h1. Iteration 5 *Target:* User-provided private key, List filtering and pagination, Robots h2. Tasks --- h3. User-provided key The application shall provide a possibility to provide his own private key or to let the application generate a key with a user-selected password. Req: FR 1.1.2, 1.1.3, 1.1.4, 2.1.2, 2.1.3, 2.1.4 h4. GUI * Web GUI - The certificate creation page shall contain a new checkbox "Generate key pair". * Web GUI - The certificate creation page shall contain a text field to specify a password for the private key. h4. Core * Rest API shall enable a PEM encoded PK to be specified within the request for creating a certificate. * Rest API shall enable a password to be specified within the request for creating a certificate. * If a password is present in the request and the private key is not present, the server generates a key protected by the given passphrase. * If a password is not present in the request and the private key is present, the server uses the given key. However, the server must do a check if the private key is not protected by a passphrase -> if yes, an error response is returned. * If both password and key are not present, the server generates a key without passphrase protection. * If both password and key are present, the server uses the given key and checks whether the given passphrase decyphers the key-> if not an error response is returned. --- h3. Validity check The application shall provide an endpoint to verify the validity of the selected certificate. Req: FR 1.3 h4. GUI * Web GUI - The certificate details page provides an indication of certificate validity. h4. Core * Rest API shall provide an endpoint /api/certificate/{id}/status to query certificate status * The application shall distinguish three types of status: _valid_, _expired_, _revoked_ --- h3. Templating Req: FR 8.1 h4. GUI * Web GUI - The certificate creation page shall provide a text area, that enables the user to specify his own extensions that will be added into the certificate. * Specified extensions must follow the OpenSSL format h4. Core * Rest API endpoint for creating a certificate shall accept extensions specification that will be passed to bottom layers and written into the certificate. * If the user specifies wrong extensions (not in compliance with the OpenSSL), the CryptographyService throws a CryptographyException, that must be intercepted by the controller and the server shall not return code 500 in that case. --- h3. Robots * The Web GUI shall be tested using automatic tests. * The tests shall utilize the Robots framework with the Selenium backend. * The test cases shall follow the user stories (user stories may require to be updated). * The tests must be integrated into the CI/CD pipeline. --- h3. Filtering The application shall enable certificate listing to be filtered and paginated. Req: FR 4.2 h4. GUI * The GUI shall provide checkboxes to select the following types of certificates: (Root CA, Intermediate CA, End Certificate) * The GUI shall provide checkboxes to select the following usages: (SSL/TLS, authentication, digital signature, CA) * _The GUI shall enable the certificate to be searched using a Common name_ - to be discussed * The GUI shall paginate the certificate list results h4. Core * Rest API (GET /api/certificates) must enable to filter the certificates using certificate type (Root CA, Intermediate CA, End Certificate) * Rest API (GET /api/certificates) must enable to filter the certificates using certificate usage (SSL/TLS, authentication, digital signature, CA) * Rest API (GET /api/certificates) must enable to filter the certificates based on the common name * Rest API (GET /api/certificates) must enable to paginate the results (page + certificates per page)