cacert-sysadm AT lists.cacert.org
Subject: CAcert System Admins discussion list
List archive
- From: samj AT samj.net
- To: "Philipp Guehring" <philipp AT cacert.org>
- Cc: CAcert System Administrators <cacert-sysadm AT lists.cacert.org>
- Subject: Re: [Cacert-sysadm] CAcert email address snafu
- Date: Sun, 17 Aug 2008 10:53:00 +0200
- List-archive: <http://lists.cacert.org/pipermail/cacert-sysadm>
- List-id: CAcert System Admins discussion list <cacert-sysadm.lists.cacert.org>
interesting to see you aleady went through much of the process I just
did about adding DNS services etc. And came to the same conclusions.
Actually registrars like .se are finding they can charge more for
secured domains, which is both good and bad for adoption.
I guess encrypting the probes is useless if they already have to log
in to respond to one, as they should.
Sampling the DNS from multiple points would help without imposing
delay and randomly delaying the probe would too, while also slowing
down attacks involving intermittent access to a victim's email, but it
affects the user experience and could probably be foiled by filters.
Sam on iphone
Sam
On 8/17/08, Philipp Guehring
<philipp AT cacert.org>
wrote:
> Hi,
>
>> I was thinking about that last night. First of all, want to
>> show control of the domain. We want to show ownership /
>> legal / responsibility control, more than any technical
>> control, because ownership and legal responsibility trumps
>> the technical control.
>>
> Yes, showing ownership and legal responsibility is better,
> but it's usually more costly. And I guess there will
> be lots of situations where it isn't possible.
> How do you proove legal responsibility for an email address?
>> Which means we should preferably be looking at the domain
>> registry. DNS is a subsidiary service to the domain
>> registry, so it will always be second best, it will never
>> show legal/responsibility control, only technical control.
>>
> Yes.
>> So, why can't a string be inserted by the member into the
>> domain registry fields? Hypothetically, "CAcert-Auth".
>>
> The problem is that the various domain registries are
> running various different databases, and provide neither
> direct nor digitally signed or somehow else secured access
> to those databases, as far as I know.
>
> Regarding whois access:
> There are no comment fields in whois, so I guess
> it will be hard to put "CAcert-auth" in it, without
> possibly violating their rules for field-contents.
>> If CAcert finds the string, it interprets the string as full
>> authorisation that CAcert is entitled to issue certificates
>> for the domain.
> That sounds like you are talking about whois service,
> but whois is similarly to DNS just a subsidiary service,
> it's not the real thing.
>
> The big problem I see here is that it just improves a bit
> on the second-level domains, but it will most likely fail
> for third-level domains, since there is usually no whois
> service for them.
> It also doesn't solve the question of Email Addresses
> or Jabber addresses, or any other service below DNS-second-level.
>
>> We won't know which certs and for which
>> domain, but we already have strong systems to control that
>> issue: a domain can only be added to one account, and if
>> someone steals a domain from another member, he'll have to
>> face the Arbitrator.
>>
>
>> This will stop anyone playing games with Microsoft.com ...
>> because MS will never put that string in there, and I'll bet
>> they have taken good steps to stop people playing with their
>> registry entries :)
>>
> But someone might do an MITM against their whois service.
>
> Or someone might hack or social-engineer the whois servers.
>
> Ouch. I actually just tried a whois query against microsoft.com
> and was a little surprised by the result I got. (See attachement)
>
> Whois isn't any more reliable than any other plaintext TCP
> service on the internet.
> microsoft.com is registered by tucows, so Microsoft
> obviously can't do much to secure Tucows (+Verisign?) whois servers.
> And they obviously aren't very good in actually securing
> the microsoft.com whois record.
>
>> Just throwing ideas around here....
>>
> The problem I see is that the registrars do not have much
> incentives to provide digitally signed or otherwise secured access to
> their database.
>
> Best regards,
> Philipp Gühring
>
>
>
>
- Re: [Cacert-sysadm] CAcert email address snafu, (continued)
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/10/2008
- Re: [Cacert-sysadm] CAcert email address snafu, Philipp Gühring, 08/10/2008
- Re: [Cacert-sysadm] CAcert email address snafu, Guillaume ROMAGNY - CAcert support, 08/10/2008
- Re: [Cacert-sysadm] CAcert email address snafu, Teus Hagen, 08/11/2008
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/11/2008
- Re: [Cacert-sysadm] CAcert email address snafu, samj, 08/11/2008
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/11/2008
- Re: [Cacert-sysadm] CAcert email address snafu, samj, 08/12/2008
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/12/2008
- Re: [Cacert-sysadm] CAcert email address snafu, samj, 08/12/2008
- Message not available
- Re: [Cacert-sysadm] CAcert email address snafu, samj, 08/17/2008
- Message not available
- Re: [Cacert-sysadm] CAcert email address snafu, samj, 08/17/2008
- Re: [Cacert-sysadm] CAcert email address snafu, Philipp Gühring, 08/10/2008
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/10/2008
- Message not available
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/18/2008
- Re: [Cacert-sysadm] CAcert email address snafu, Sam Johnston, 08/19/2008
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/19/2008
- Re: [Cacert-sysadm] CAcert email address snafu, Sam Johnston, 08/20/2008
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/22/2008
- Re: [Cacert-sysadm] CAcert email address snafu, Sam Johnston, 08/22/2008
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/28/2008
- Re: [Cacert-sysadm] CAcert email address snafu, Sam Johnston, 08/28/2008
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/29/2008
Archive powered by MHonArc 2.6.16.