CAcert System Admins discussion list

["Sam Johnston" <samj AT samj.net>]

Ian,

If you propose something which is mandatory you will raise the bar /significantly/ for adding domains to accounts (currently you have to do nothing - my proposal assuming we need to 'fix' this is to give a number of options), and if you propose something which is optional and anything other than the path of least resistance then nobody will use it.

How were you expecting that this check would work anyway, given it can't be automated? We need to have domains 'assured' too now?

Sam

On Fri, Aug 22, 2008 at 3:17 AM, IanG <iang AT cacert.org> wrote:

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