CAcert System Admins discussion list

[IanG <iang AT cacert.org>]

Quick reply!


Sam Johnston wrote:
> On Tue, Aug 19, 2008 at 8:10 PM, IanG <iang AT cacert.org 
> <mailto:iang AT cacert.org>> wrote:
>  
>
>     Right now, domain and email checking doesn't fly.  Over to you!
>
>
> I agree that domain checking could be improved by checking for CNAMEs, 
> HTML files, META tags, etc. This can be done once or on an 
> ongoing/random basis. It proves ongoing control over the [sub]domain.


Remember, control is just a poor way to show delegation of 
control from ownership :)  In the absence of an easy way to 
show delegation of control, we show actual control instead, 
and hope that's good enough.


>         This is a non-starter. If you corrupt the WHOIS you can lose
>         your domain:
>
>         "/Please remember that under the terms of your registration
>         agreement, the provision of false Whois information can be
>         grounds for cancellation of your domain name registration./"
>
>
>     1. the information isn't false.  Nor is it misleading, deceptive,
>     bad faith (see ICANN rules), negligent, or any other "bad thing."
>
>
> /At least annually, a registrar must present to the Registrant the 
> current WHOIS information, and remind the registrant that provision of 
> false WHOIS information can be grounds for cancellation of their domain 
> name registration. Registrants must review their WHOIS data, and make 
> any corrections./
>  
> So where do you put this CAcert-auth tag (noting that it has to somehow 
> link back to the account of the recipient so it needs to be an email, 
> random number, etc)?


I put it in the Technical-Contact Organisation.  Sure, there 
are some implementation details to think about.


> I wasn't aware of a field for this purpose

There is an entire contact for Technical delegation.  It 
seems to fit.

> and 
> overloading another could well be considered as false/corrupt.


Sigh.  This "consideration" is neither likely nor logical. 
The provisions stated above, now twice by you, are *legal 
thinking* and legal thought doesn't work that way.

Of course, they ... the wipolizerei ... want everyone to be 
scared of their own shadows ... I explained in the previous 
post what they really want, which is something entirely 
different.


> More importantly it means that in order to do so I have to turn off 
> whois privacy, revealing my identity publicly which is something that 
> many people don't want to do (for me it's mostly to avoid spam).


This is the same as before:  this method described is not a 
sole, complete and necessary step.  It can only be an option.

(I'm not sure of this privacy bit.  When I looked at the 
registrar recently, it charged as much as the domain cost to 
turn on privacy.  It seems a little excessive.)


> A 
> security conscious organisation even suggesting, let alone *requiring*, 
> one to disable a privacy feature would be a laughingstock.


Strawman.  Nobody is suggesting that a privacy feature be 
disabled.


>         It doesn't work for email. It doesn't work for chat. It doesn't
>         work for OpenID.
>
>
>     If you are saying that it won't work for all the users of these
>     products, then sure.  I agree.  But that's a bit like the current
>     system:  it doesn't work for all reliance purposes, only some, and
>     them not adequately.
>
>     If you are saying that these products do not use domains in certs,
>     then I would disagree.  It should work in any circumstance where a
>     Member can get at the domain registry.  If not, then not.
>
>     (It works perfectly for most all organisation purposes!!!)
>
>
>
>         It just works for domains and it's slow (WHOIS updates can be
>         infrequent), unreliable (varies from TLD to TLD)
>
>
>     It may be slow but it is persistent, as against a domain ping which
>     *may be* faster but only lasts for a few second.
>
>
> CNAME, HTML, META, etc. checks can be done repeatedly and/or randomly. 
> Pings cannot.


Right, they also can be done, for websites.  I'm not sure 
what domain owners are going to do for email addresses though.


>         and own't work for 2LDs and below,
>
>
>     I explained that before.  It works perfectly for lower domains.  The
>     owner delegates all of it.  That's it.  The fact that the lower
>     domain *controllers* cannot change that delegation is ... tough. 
>
>
> So where you have a domain, eg a US state gov, shared between different 
> organisations, they are short of luck unless they can convince the top 
> level authority to take an interest in scratching their itch...


Well, if you don't own your domain, you don't have all the 
rights.  What's so hard about that?


>     (It's about ownership, not control....)
>
>
> Why is proving control inadequate? Conversely, why is ownership required?


Proving control is not as perfect as all that.  The problem 
is that control can be lost by an owner (c.f., spoofing, etc).

Proving ownership isn't perfect also.  As outlined...

However, the two could work together.  Ideally, we would 
like something like two independent verifications:

    * website change
    * registry change
    * dns change
    * email ping probe

If we get 2 of the above, then we have shown a measure of 
independence.  Not perfect anti-correlation, mind, but 
something.


>     Showing control is good too.  However, if you think handling domains
>     is too hard for users, then you can give up on DNS.  No users that
>     I've ever come across deal with DNS.  Even experienced techies run
>     like hell from that.
>
>
> So they can mess with HTML/META tags.


They can do that too.  For websites / server certs, sure.


>         Ownership of the resource itself is, so far as I can tell,
>         unnecessary for our security model.
>
>
>
>     LOL....  Onership of the resource is *entirely sufficient* to
>     delegate the authority to use or control or issue certs, in any way
>     possible or supported.
>
>
> Sufficent, yes. Required, no.


Actually, required.  If the owner has not delegated control, 
then it is a stolen domain.

Our use here of the word 'control' is really meant to imply 
and include two things:

   * 'delegation of control by owner'
   * 'actual control by delegee'


>     Ownership trumps control and security. 
>
>
> Nonetheless, control is sufficient and far more convenient.


It does not address the undelegated domain.

(However, we can show ownership otherways than by changes in 
the registry.  If there is massive resistence to the issue 
of using registries to show ownership, then we'll have to 
use one of the other methods.)


>     E.g., if a domain owner comes to CAcert and states that all certs
>     should be revoked, and she has lost control over the certificate,
>     what is the Arbitrator going to do?  Revoke. It's hers.
>
>     E.g., In a recent San Francisco case, the security model locked out
>     the managers.  The guy who did that was arrested and hit with
>     $5,000,000 bail.  He's toast.
>
>     Ownership trumps control!  Never forget that!
>
>
> Maybe so, but if the owner is unhappy they can take control forcibly (as 
> in the above case). In the mean time, control is sufficient.


Well, of course.  control is sufficient until it is not. 
Reminds me of the sex.com saga.  The owner got it back, 
after how many years?

iang