Iteration 5 » Historie » Verze 5
Jan Pašek, 2021-04-22 15:33
1 | 1 | Jan Pašek | h1. Iteration 5 |
---|---|---|---|
2 | 2 | Jan Pašek | |
3 | |||
4 | *Target:* User-provided private key, List filtering and pagination, Robots |
||
5 | |||
6 | h2. Tasks |
||
7 | |||
8 | h3. User-provided key |
||
9 | |||
10 | 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. |
||
11 | |||
12 | 3 | Jan Pašek | Req: FR 1.1.2, 1.1.3, 1.1.4, 2.1.2, 2.1.3, 2.1.4 |
13 | |||
14 | 2 | Jan Pašek | h4. GUI |
15 | |||
16 | * Web GUI - The certificate creation page shall contain a new checkbox "Generate key pair". |
||
17 | * Web GUI - The certificate creation page shall contain a text field to specify a password for the private key. |
||
18 | |||
19 | h4. Core |
||
20 | |||
21 | * Rest API shall enable a PEM encoded PK to be specified within the request for creating a certificate. |
||
22 | * Rest API shall enable a password to be specified within the request for creating a certificate. |
||
23 | |||
24 | * 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. |
||
25 | |||
26 | * 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 |
||
27 | 4 | Jan Pašek | not protected by a passphrase -> if yes, an error response is returned. |
28 | 2 | Jan Pašek | |
29 | * If both password and key are not present, the server generates a key without passphrase protection. |
||
30 | |||
31 | 1 | Jan Pašek | * 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. |
32 | 4 | Jan Pašek | |
33 | h3. Validity check |
||
34 | |||
35 | The application shall provide an endpoint to verify the validity of the selected certificate. |
||
36 | |||
37 | 5 | Jan Pašek | Req: FR 1.3 |
38 | |||
39 | 4 | Jan Pašek | h4. GUI |
40 | |||
41 | * Web GUI - The certificate details page provides an indication of certificate validity. |
||
42 | |||
43 | h4. Core |
||
44 | |||
45 | * Rest API shall provide an endpoint /api/certificate/{id}/status to query certificate status |
||
46 | * The application shall distinguish three types of status: _valid_, _expired_, _revoked_ |
||
47 | 5 | Jan Pašek | |
48 | h3. Templating |
||
49 | |||
50 | Req: FR 8.1 |
||
51 | |||
52 | h4. GUI |
||
53 | * 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. |
||
54 | |||
55 | * Specified extensions must follow the OpenSSL format |
||
56 | |||
57 | h4. Core |
||
58 | |||
59 | * Rest API endpoint for creating a certificate shall accept extensions specification that will be passed to bottom layers and written into the certificate. |
||
60 | * 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 |
||
61 | return code 500 in that case. |
||
62 | |||
63 | h3. Robots |
||
64 | |||
65 | * The Web GUI shall be tested using automatic tests. |
||
66 | * The tests shall utilize the Robots framework with the Selenium backend. |
||
67 | * The test cases shall follow the user stories (user stories may require to be updated). |
||
68 | * The tests must be integrated into the CI/CD pipeline. |