| | 110 | === Minimizing Windows of Vulnerability === |
| | 111 | |
| | 112 | Depending on the timings/delays of fetching keys, signatures, and revocations from keyservers, there is a window during which an invalid key will be treated as valid. How do we minimize these windows without inserting significant delay in the common use case? |
| | 113 | |
| | 114 | === Chained Trust specific to account owner === |
| | 115 | |
| | 116 | It seems like a GPG keyring should provide enough information to describe basic server-wide trust rules. But what if you wanted a trust rules like: |
| | 117 | * for account `foo`, trust UserID certifications from key XYZ as well as the usual system-wide introducers, or |
| | 118 | * for account `foo`, allow chained introductions through any key with already-certified User ID `Fubar <foo@example.org>` |
| | 119 | How would this be implemented? |
| | 120 | |
| | 121 | === Minimizing Bad Incentives === |
| | 122 | |
| | 123 | Some users will always want to share access to their account, even if it is discouraged by the system administrators. Ultimately, since users can share authentication tokens (or keyboards!) with each other, there is nothing that can be done to prevent this absolutely. How do we make this framework flexible enough to allow users who want to share access to do so without doing things that violate the web of trust? |
| | 124 | |
| | 125 | Are there any other bad incentives that this framework might create that we should try to mitigate? |
| | 126 | |