Skip to Content.
Sympa Menu

cacert-policy - Re: [CAcert-Policy] Why is identity needed to authenticate domains?

Subject: Policy-Discussion

List archive

Re: [CAcert-Policy] Why is identity needed to authenticate domains?


Chronological Thread 
  • From: mfolimun AT elitemail.org
  • To: "Policy-Discussion" <cacert-policy AT lists.cacert.org>
  • Subject: Re: [CAcert-Policy] Why is identity needed to authenticate domains?
  • Date: Fri, 11 May 2007 22:27:58 +0000
  • List-archive: <http://lists.cacert.org/cgi-bin/mailman/private/cacert-policy>
  • List-id: Policy-Discussion <cacert-policy.lists.cacert.org>

On Fri, 11 May 2007 14:00:04 +0200, "Ian G" 
<iang AT systemics.com>
 said:

> But I don't think it is to provide *domain-control* certs 
> for free.  That's just something that is done right now as 
> part of the above mission.  CAcert might decide one day to 
> drop them completely.
> 
> Also, CAcert's mission is likely to limit its bounty in the 
> future to just registered users ... (with the assumption 
> that they become Assured.)

This is unfortunate. I had hoped your goal was to provide
a widely accepted certificate authority that enabled the 
average joe to secure his domain content. This is something
badly needed.. :(

General web of trust and document certification is something
already done by the much more extensive (and more easily 
accessible and usable) GPG web of trust.

> (2) But, most the people who *implement* PKI and 
> certificates believe something else.  They believe that 
> crypto should only be used from person to person in an 
> environment of reliance.  I agree with that, to the extent 
> that it exists, as a world.

This world does not exist for ssl-style certs. It never 
will. SSL certs are by their nature a many-to-many relation
where an authority (you) certifies other entities as being 
who they  say they are to a multitude of users. For SSL, 
the entity certified is a domain name, tied to to the 
DNS system.

> CAcert has to live in both worlds.  So far it is doing this 
> double life fairly well.  From both sides it looks sort of 
> kinda like what is expected.
> 
> But it's not perfect, I grant.  Your complaint here is 
> fairly minor compared to the complaints that CAcert receives 
> from the PKI world.

Hrmm, I'm not aware of these complaints. I approached this issue
from the point of view that the best way to achieve the goal of
a CA cert that is accepted by most browsers, email clients,
and other SSL users is to get it used by a large number 
of people.

My view was if you make adoption easy for people, at some point 
a tipping point will be reached where the browsers and email 
clients say "Hey, these guys are doing a good job of certifying 
domain owners actually own their domains. And lots of people 
use them. Let's include them." This is ultimately what SSL 
for web and email is about. Certifying domains.

I believe the only way for this to happen is to make adoption
easy, and secure for its purpose. IMO, authenticating domains
is the security you need, not authenticating people. After all
people do not map cleanly to domains.

> > If I demonstrably control all properties of domain X, there is no harm 
> > in you certifying I am domain X, unless I have hacked domain X, stole 
> > its mail, stole the passwords to the registrar, and hijacked its 
> > webserver, and convinced their ISP to update reverse DNS. All without 
> > the domain admin knowing.. If I am this much of an uber-ninja, why don't 
> > I just do this to domains Y and Z that have already been granted
> > CAcerts, and steal their private keys?
>  
> So, you answered your own question by explaining the 
> uncertainty.

Ok, I suppose this is understandable. As an alternative, 
how about this: if an unassured user uses a the 6 month 
cert without event/complaint, and then repeats the same 
3 step process:

 1. Email to postmaster
 2. Point subdomain to requested CAcert random IP
 3. Post randomly generated CAcert.org webpage/image on domain

6 months later, they then have a demonstrated a yet higher degree 
of certainty of ownership of the domain, because they have been 
using it for 6 months without incident and still have control. 
It is much much less likely that an uberninja would manage to escape
6 months of usage of a domain without anyone noticing... Surely
this entitles them to a longer cert the second time around?

> > But this is NOT what you do! This is what the GPG web of trust does! 
> > What YOU do is certify that content that claims to be from domain X 
> > *really is* from domain X. Particular individuals have nothing 
> > to do with the content you certify.
>  
> Sorry, where did you read that?  The CPS doesn't say that, 
> did this come from anywhere in particular?

http://wiki.cacert.org/wiki/SubmitCsr - ;

"Basically unless you assure your company nothing else 
except for commonNames and subjectAltNames will appear 
on your certificate, the other fields are removed"

It would seem you do not provide any form of individual
identity on your certs, just commonName/domain.

> As a long time promoter of psuedonymous security, I know 
> what you are saying.  But, consider this:  you can do 
> psuedonymous security by yourself.
> 
> OTOH, if you do it with CAcert, then you have to offer 
> CAcert something, else it has no interest in taking on the 
> liability and risk of working with you.  What would you offer?
> 
> Or, are you simply asking CAcert to issue you with a 
> self-signed cert?  As in, do the heavy lifting of creating 
> and running the self-signing CA for you?
>
> That's maybe a valuable product ... who would like that?

Not really. Not if it meant a new CA for each site for the
end-user to install.

What I'm offering to cacert.org is a pathway to widespread 
adoption of your CAcert.org root cert in as many people's 
browsers as possible. I thought that was a goal of yours.

I am trying to encourage you to create an environment where 
regular people on the Internet have an incentive to 
add your certificates to their browser, and thus drive
adoption by browser makers from the ground up. IMO, the best
way to create this scenario is to make it easy (yet still
as secure as possible within the DNS domain model of 
identity) for people to create domain certificates.

Sort of a "grass roots"/"tipping point" effort for browser 
acceptance of your root cert. I do not believe you will
reach this tipping point if people have to fly to 
Germany/Ohio or wherever to show their ID documents to some
volunteer they have never met and don't otherwise trust.

Perhaps you create a second root cert for people who want
this sort of "quick and drity" ssl service? But IMO, that 
should only be done if you still cannot reach consensus 
that after 6 months of continued usage, there still
is no additional assurance that the user of the domain
actually owns it (which I find a bit ridiculous, but hey
it's not my decision).


-- 
  
  
mfolimun AT elitemail.org

-- 
http://www.fastmail.fm - Access all of your messages and folders
                          wherever you are





Archive powered by MHonArc 2.6.16.

Top of Page