On 02/07/2012 06:04 PM, Kai Engert wrote:
> The CA will remember the assocation {IP, certificate}. In future
> requests, as long as this requesting IP requests a voucher for the same
> certificate, the described bidirectional authentication and verification
> will be sufficient.
Just a technicality: {IP, list of certificates, FQDN} instead of {IP,
certificate} (see my previous post to dev.tech.crypto).
We should also investigate how various cloud services (Amazon, Akamai,
...) handle IP-to-server mapping. I don't know how often does that change.
> What happens if an attacker uses a false certificate for a domain that
> is not yet using SSL? The worst that can happen is a temporary denial of
> service attack to start using SSL, because it makes it harder for the
> real domain owner to switch away from the false bookkeeping, which is
> being kept by the vouching authorities. However, as soon as the false
> certificate used by the attacker has been revoked, the vouching
> authorities will revert to the "empty" bookkeeping state. Also, because
> vouchers are per IP, the real domain owner can simply ensure that a
> different IP address will be used for the real server. Also, it should
> probably be defined that the bookkeeping done by vouching authorities
> (the pairs of {IP, certificate}) will expire 10 days after no more
> requests using a valid certificate were made for the given IP.
Sovereign Keys need to solve the same issue:
https://git.eff.org/?p=sovereign-keys.git;a=blob;f=issues/transitional-considerations.txt;h=fa3b1591820baf1f2f62740f1f0e8b7998c29174;hb=HEAD
What happens if domain is sold and former owner won't cooperate with
issuing new voucher or hand over private key for former server cert? How
can a vouching CA know that new owner is not an attacker?
I'll post a note about this discussion to sovereign-keys list, I think
they'd be interested as well.
Ondrej
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
