[cryptography] naming is hard as CAs now get to demonstrate

Erwann Abalea eabalea at gmail.com
Sat Apr 13 06:06:11 EDT 2013


Even with only perfect public CAs that do not issue certificates for
unapproved namespaces, the problem persists.

A company can have a private namespace (TLD) for its internal use, and a
private CA, trusted by its employees. The mail server would have a name in
this private namespace, with a certificate issued by this CA. Employees
laptops connect to this mail server using the private name, everything
works fine.
When an employee takes his laptop outside of the private network, the MUA
tries to connect to resolve the private name of the mail server and connect
to it. If this private TLD becomes public, the owner can get a valid public
certificate for his brand new TLD, and the previous employee would then
connect to an existing mail server with a valid public certificate and send
its credentials.

No public CA are involved in this scenario, and ".corp" is a TLD widely
used for internal networks.



2013/4/13 ianG <iang at iang.org>

> On 13/04/13 04:50 AM, dan at geer.org wrote:
>
>>
>> naming is hard as CAs now get to demonstrate
>>
>
> ...
>
>  Once ICANN approves the
>> gTLD, the attacker has a legitimate certificate to go about performing
>> man-in-the-middle attacks.
>>
>
>
> By waiting for ICANN approval of a namespace, CAs can now validly issue
> name clashes within an approved space, and thus everyone can rest easy.
>  That makes sense.
>
>
>
> iang
>
>
> ______________________________**_________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/**mailman/listinfo/cryptography<http://lists.randombit.net/mailman/listinfo/cryptography>
>



-- 
Erwann.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20130413/b702c81d/attachment.html>


More information about the cryptography mailing list