Conversation
mgallien
requested review from
alperozturk96,
artonge,
marinofaggiana and
tobiasKaminsky
| 2. Query the user certificate by sending GET request to the `/ocs/v2.php/apps/end_to_end_encryption/api/v1/public-key` endpoint and sending a JSON encoded `users` parameter containing the specified UIDs | ||
| 3. If the user has not yet set up E2E and thus no public key, it will not be possible to share with the user. | ||
| A warning should then be shown. | ||
| 4. Verify that the certificate is valid. |
There was a problem hiding this comment.
How is this done? Against which public key?
There was a problem hiding this comment.
usual validation rules for a x509 certificate (like what a browser would do)
(start valid date, end valid date, not self-signed, not revoked, signing certificates known and valid, ...)
There was a problem hiding this comment.
we generally are unable to do this for certificates generated by the Nextcloud embedded CA
to check if we could modify the behavior to always use standard certification validation code (again what a browser would check)
There was a problem hiding this comment.
signing certificates known and valid
I was concerned about this step. Checking that the x509 certificate is signed by the public key of the NC instance is easy. But who is signing the certificate in this case? A publicly known CA? When you say "like what a browser would do", you mean having a big list of trusted CA, and validating the certificate against them?
There was a problem hiding this comment.
yes
to do that I needed to fetch intermediate CA certificates from the windows store and let them known to Qt SSL API for validation purposes
I highly doubt that is currently relevant for web end-to-end encryption. I would expect a dedicated development to be needed to fetch the certificate from an user store instead of from the Nextcloud server app
There was a problem hiding this comment.
Maybe we should allow providing the root cert then on the server as a capability?
There was a problem hiding this comment.
but then the root cert could be exchanged by malicious attacker/admin?
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
| 5. Client stores the private key in the keychain of the device. | ||
| 6. The mnemonic is stored in the keychain of the device (ideally with spaces so it can be shown more readable). | ||
|
|
||
| A client detecting a certificate that has not been issued by the server public key and that has no support for secure USB token or is not finding the certificate on such a valid USB secure token should disable end-to-end encryption. |
There was a problem hiding this comment.
| A client detecting a certificate that has not been issued by the server public key and that has no support for secure USB token or is not finding the certificate on such a valid USB secure token should disable end-to-end encryption. | |
| A client detecting a certificate that has not been signed with the servers public key and that has no support for secure USB token or is not finding the certificate on such a valid USB secure token should disable end-to-end encryption. |
maybe?
| 6. The mnemonic is stored in the keychain of the device (ideally with spaces so it can be shown more readable). | ||
|
|
||
| A client detecting a certificate that has not been issued by the server public key and that has no support for secure USB token or is not finding the certificate on such a valid USB secure token should disable end-to-end encryption. | ||
| In case certificate are stored on secure USB token and generated outside the Nextcloud server app, not falling back to less secure software stored certificate should not be permitted. |
There was a problem hiding this comment.
| In case certificate are stored on secure USB token and generated outside the Nextcloud server app, not falling back to less secure software stored certificate should not be permitted. | |
| In case certificates are stored on secure USB token and generated outside the Nextcloud server app, falling back to less secure software stored certificate should not be permitted. |
"not falling back should not permitted"?
meaning it should be permitted to fall back or it should be forbidden to fallback to less secure tokens?
susnux
left a comment
susnux
left a comment
There was a problem hiding this comment.
just some comments to clarify I understood it correctly, but for me this makes sense 👍
| The clients do the following when trying to establish a trust relationship to another user: | ||
| Alternatively, the certificates may be entirely managed by an external certificate authority (CA). In such cases, the workflow has to be different. | ||
|
|
||
| The clients do the following when trying to establish a trust relationship to another user when certificates are generated directly by the end_to_end_encryption Nextcloud app: |
There was a problem hiding this comment.
| The clients do the following when trying to establish a trust relationship to another user when certificates are generated directly by the end_to_end_encryption Nextcloud app: | |
| The clients do the following when trying to establish a trust relationship to another user when certificates are generated directly by the `end_to_end_encryption` Nextcloud app: |
| 1. It is valid, it will be used. | ||
| 2. It is no longer valid, the client will continue at 2. | ||
| 2. If none is available, the client will continue at 2. | ||
| 2. Query the user certificate by sending GET request to the `/ocs/v2.php/apps/end_to_end_encryption/api/v1/public-key` endpoint and sending a JSON encoded `users` parameter containing the specified UIDs |
There was a problem hiding this comment.
| 2. Query the user certificate by sending GET request to the `/ocs/v2.php/apps/end_to_end_encryption/api/v1/public-key` endpoint and sending a JSON encoded `users` parameter containing the specified UIDs | |
| 2. Query the user certificate by sending GET request to the `/ocs/v2.php/apps/end_to_end_encryption/api/v2/public-key` endpoint and sending a JSON encoded `users` parameter containing the specified UIDs |
| 2. It is no longer valid, the client will continue at 2. | ||
| 2. If none is available, the client will continue at 2. | ||
| 2. Query the user certificate by sending GET request to the `/ocs/v2.php/apps/end_to_end_encryption/api/v1/public-key` endpoint and sending a JSON encoded `users` parameter containing the specified UIDs | ||
| 3. If the user has not yet set up E2E and thus no public key, it will not be possible to share with the user. |
There was a problem hiding this comment.
| 3. If the user has not yet set up E2E and thus no public key, it will not be possible to share with the user. | |
| 3. If the user has not yet set up E2EE and thus no public key, it will not be possible to share with the user. |
| 2. Query the user certificate by sending GET request to the `/ocs/v2.php/apps/end_to_end_encryption/api/v1/public-key` endpoint and sending a JSON encoded `users` parameter containing the specified UIDs | ||
| 3. If the user has not yet set up E2E and thus no public key, it will not be possible to share with the user. | ||
| A warning should then be shown. | ||
| 4. Verify that the certificate is valid. |
There was a problem hiding this comment.
Maybe we should allow providing the root cert then on the server as a capability?
4 participants
No description provided.