Eliot Lear <l...@cisco.com> wrote:
>> No. There are several steps before we get to raw public keys.
>>
>> The first is that the duration of the Staples could be lengthed to
accomodate
>> anticipated down time for the (now) critical OCSP responder.
>> A second part is that perhaps staples could be provisioned in advance
for the
>> server to cover for planned maintenance periods. I don't imagine this
is in
>> any protocol, but could be added.
> But to what end? We don’t even know if these devices can reasonably
> deal with any secure notion of time. Even checking cert expiry is a
> bit questionable in some cases, especially if the cert has been seen
> before, and the device is of someone critical value. And it’s not
> clear what the value is with a lengthy expiry.
okay, but this is clearly a problem regardless.
Devices without known good time can't do very many useful things, and
probably just could ignore the staple.
But, laptops and mobiles do have good time, and they can do the right thing.
>> The second is, I think, that the EAP server (Authentication Server),
would run
>> an OCSP responder locally so that it can mint it's own staples.
>> AFAIK, each certificate can point to a different OCSP signer.
> Does anyone actually do that?
I dunno, but it is possible as far as I can tell.
>> 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.
>> 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.
>> 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.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
