| | 2 | |
| | 3 | === Status wiki === |
| | 4 | |
| | 5 | We believe that: |
| | 6 | * On client machines, we can unset allow_weak_crypto once the users on the machine have strong keys and the servers they communicate have strong keys. |
| | 7 | * On application servers, we can unset allow_weak_crypto once the users connecting have a vaguely recent kerberos and the server has a strong key. (If it accepts passwords, the users also need to have a strong key.) |
| | 8 | * On the KDC, we don't care because it doesn't run Debathena. |
| | 9 | |
| | 10 | Key rolling status: |
| | 11 | * We believe that the cert update process will roll keys, so all (active-ish) users should have updated keys by ~September even without any additional work. |
| | 12 | * AFS servers are hard to roll, but mostly don't count because of krb5_allow_weak_crypto.html (see comment:3). |
| | 13 | * Except for AFS (above), Server Operations' keys have all be updated (see comment:4). |
| | 14 | * IMAP servers aren't yet rolled (do they have old software?) |
| | 15 | * SIPB services are generally rolled (contacting the maintainers is probably reasonable for anything that isn't, but we think that's done) |
| | 16 | * Presumably user outreach is required to get other application servers to roll their keys. |
