Skip to Content.
Sympa Menu

cacert-sysadm - Re: [Cacert-sysadm] CAcert email address snafu

cacert-sysadm AT lists.cacert.org

Subject: CAcert System Admins discussion list

List archive

Re: [Cacert-sysadm] CAcert email address snafu


Chronological Thread 
  • From: samj AT samj.net
  • To: IanG <iang AT cacert.org>
  • Cc: CAcert System Administrators <cacert-sysadm AT lists.cacert.org>
  • Subject: Re: [Cacert-sysadm] CAcert email address snafu
  • Date: Tue, 12 Aug 2008 15:24:31 +0200
  • List-archive: <http://lists.cacert.org/pipermail/cacert-sysadm>
  • List-id: CAcert System Admins discussion list <cacert-sysadm.lists.cacert.org>

Interesting idea except that you can lose your domain for having
incorrect whois info. Still breaks with whois privacy too.

You are right in saying that legal control is different than technical
and often involve different people but it doesn't really matter.

I still don't see any good reason to get OA mixed up with domains
here... what is the problem with an org associating itself with
arbitrary domains anyway? If it wants to issue certificates containing
it's legal name for domains it doesn't own then so be it. Similarly if
I want a contractor,say my accountant, to have my company name in his
email cert with his ISP email address then that's fine too.

Finally, if I just want to have a domain managed by multiple accounts
then we don't care about the org because the user already has proven
control over the domains themselves!

Sam


On 8/12/08, IanG 
<iang AT cacert.org>
 wrote:
> samj AT samj.net
>  wrote:
>> I would suggest that there are some weaknesses that can be fixed, for
>> example by sampling the DNS from multiple locations, and that this is
>> otherwise strong enough for one time email verifications. That is,
>> enough to say that this person had read access to that email address
>> at that partiular instant. Using mail replies could give us a better
>> audit trail and would raise the bar if we were sensitive about SPF,
>> dkim failures etc.
>>
>> Also if the token is to be embedded into the link then there should be
>> another cancel link which works even after acceptance, or at least
>> authentivation required so as automated link checkers don't pass the
>> check.
>>
>> The separate question of domain verification is less clear. Auth codes
>> would be interesting, only not sure they can be verified outside the
>> transfer process and they are not universal, as CNAME, HTML and META
>> checking are.
>
> 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.
>
> 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.
>
> So, why can't a string be inserted by the member into the
> domain registry fields?  Hypothetically, "CAcert-Auth".
>
> If CAcert finds the string, it interprets the string as full
> authorisation that CAcert is entitled to issue certificates
> for the domain.  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 :)
>
> Just throwing ideas around here....
>
> iang
>
>




Archive powered by MHonArc 2.6.16.

Top of Page