[Trimming] > On 26 Oct 2020, at 16:26, Michael Richardson <[email protected]> wrote: > > >>> While this degenerate case of Authentication Server + OCSP Signer on the >>> same >>> machine is kinda dumb from a overall security point of view, it's still >>> better than raw public keys. > >> Yes. Let’s think about who OCSP is protecting in this case. It’s >> protecting the client from the Authentication Server, in theory. > > Yes, from compromises of the Authentication Server via loss of control of > private key.
And so the authentication server and OCSP signer being on the same device itself represents both a scaling problem and a security problem. Just imagine having to manage all of that. > >>> If the OCSP signer is moved to some TPM then >>> there is a win. Not all TPMs can provide the performance required to handle >>> the server certificate, but resigning an OCSP Staple once every ten minutes >>> or something shouldn't be a problem. > >> If this is the case, then a public key could be moved into the the TPM just >> as easily. > > If the TPM can accomodate thousands of signatures per minute, which fTPMs > probably can accomodate (same CPU, just different context), then sure. > Many older, i2c interfaced physical-TPMs do not accomodate that rate. I’ll admit to only secondary interest in performance. That is- one can optimize around this. But managing naked public keys of servers themselves is not scalable from a key management perspective. >>> The third is, I think, that the EAP server runs an entirely self-contained >>> private CA. The OCSP responder is now clearly an integral part of the local >>> system. > >> Again, what threat are we protecting against? > > The self-contained CA might have a passphrase, so there is some accomodation > updating the signing key for new algorithms, etc. while the trust anchor > which is distributed is appropriate pessimistic. > I guess the issue I’m having is that stapling is requiring more connectivity than may be present, and making it a MUST means that we are making very VERY broad deployment assumptions. It is WAY too early for that. Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
