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: "Sam Johnston" <samj AT samj.net>
  • To: IanG <iang AT cacert.org>
  • Cc: Philipp Guehring <philipp AT cacert.org>, CAcert System Administrators <cacert-sysadm AT lists.cacert.org>
  • Subject: Re: [Cacert-sysadm] CAcert email address snafu
  • Date: Wed, 20 Aug 2008 16:16:54 +0200
  • List-archive: <http://lists.cacert.org/pipermail/cacert-sysadm>
  • List-id: CAcert System Admins discussion list <cacert-sysadm.lists.cacert.org>

On Tue, Aug 19, 2008 at 8:10 PM, IanG <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.
 

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 wasn't aware of a field for this purpose and overloading another could well be considered as false/corrupt.

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). A security conscious organisation even suggesting, let alone requiring, one to disable a privacy feature would be a laughingstock.


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.
 

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...
 
(It's about ownership, not control....)

Why is proving control inadequate? Conversely, why is ownership required?

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.
 

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.
 
Ownership trumps control and security.

Nonetheless, control is sufficient and far more convenient.
 
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.

Sam
 



Archive powered by MHonArc 2.6.16.

Top of Page