Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
> >>>>> "Eric" == Eric Rescorla <ekr@rtfm.com> writes:
> Eric> Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
> >> That's really not a problem for IKE. If the right goop isn't there,
> >> you loose.
>
> Eric> Uh, then why bother having caching at all? If you're going to have
> Eric> caching you have to have cache invalidation.
>
> Don't all these fancy certificates come with expiry dates?
Not all rollovers or reconfigurations happen on expiry dates.
> >> That's why we want to just send the URL (or URN if you want) where the
> >> certificate, whatever chain you need, and maybe the CRL, can be found.
>
> Eric> And if the implementation can't do HTTP you're completely SOL--or
> Eric> rather you have to send the whole chain over UDP, which is what you
> Eric> say you're trying to avoid.
>
> No, if the implementation can't do HTTP, then I buy another implementation,
> or I preconfigure the appropriate chain, or I simplify the trust model.
Why not just get the design right in the first place?:
> The problem that people doing certificates keep running into is that they
> keep thinking that they are building the "global PKI" and run into how do
> two random people communicate securely, even though there isn't a global PKI.
>
> This is why you say things like this - you assume that the two parties are
> random people and don't have any clue about each other's situation. So far,
> there isn't anyone that wants to do this kind of thing that is using pkix
> certificates.
This works just fine with TLS.
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/