Policy-Discussion

[mfolimun AT elitemail.org]

On Sun, 13 May 2007 02:34:48 +0200, "Philipp Gühring" 
<pg AT futureware.at>
said:
> I guess there is some misunderstanding here. I would suggest that you
> read up the discussions that happened on the policy mailinglist to 
> understand Ian´s misunderstandable statement.

Hrmm.. If these archives were public & searchable, perhaps I could find 
this easier? :)
 
> CAcert isn´t just issueing SSL style certs, it´s also issueing client 
> certificates which can be used for S/Mime, PDF Signatures, ... or even 
> Codesigning certificates.

Ah, ok. Well then consider my comments only applicable to server SSL
certificates then. I completely understand the need for rigorous 
identity checks for certificates that DO certify individuals, such
as code signing and client certificates.
 
> > 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
> 
> Yes. 
> 
> >  2. Point subdomain to requested CAcert random IP
> 
> I wouldn´t start changing the procedure on the renewal, I would suggest
> that we keep the same email procedure.
> Hmm, adding a DNS entry for CAcert is an interesting idea, but I guess
> that this is more difficult for most people than the email receiving step.
> But we could think about adding it as an optional alternative mechanism
> to the current email verification.
> 
> >  3. Post randomly generated CAcert.org webpage/image on domain
> 
> That´s a security risk and was already voted against (if I remember 
> correctly). The arguments were the large amount of website hacks, php 
> exploits and CMS systems if I remember correctly.

Well I am arguing not for these as independent alternatives, but as 
the conjunction. Mail can be hacked, web can be hacked, registrar can 
be hacked. And all can be hacked independently of the others, but 
hacking all 3 without notice is a much more difficult task. Therefore, 
I do think it is wise to verify by multiple mechanisms, just in case 
one of them is compromised via security flaw, but the others are not. 

Also, all three of these can be easily verified with a single 
program/script, not just by hand, which is a double-plus-good bonus 
for admin overhead.

The key as I see it is that someone doing all these things to get
verified takes maybe an hour tops (possibly a day for DNS to propagate), 
where as finding an assurer and meeting them can take weeks, or even 
months.

> > 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?
> 
> Yes, the concept of increasing the certificate lifetime after each period
> of undisputed usage of certificates for the domain makes sense to me.
> Could you research the current situation (of all the kinds of
> certificates and the other exceptions, ...) and write up a detailled 
> proposal please? Perhaps something like 3 months per undisputed lifetime? 
> So 6 months at the beginning, then 9 months, then 12 months, ...
> Hmm, up to 2 years?

This sounds acceptable to me. All I really want to avoid is having to 
renew my server certificate every 6 months. Though I think perhaps it 
should double. 6 months, 1 year, then 2 years. 9 months is a weird 
quantity of time. As is 15 months, 18 months, etc.

> While we are at certificate lifetimes:
> I recently stumbled across the problem of client certificate lifetimes in 
> EMail (S/Mime usage). The problem is that it´s currently far more effort
> to renew a client certificate in EMail usage, since without a LDAP or 
> better 
> cert-distribution mechanism, you easily run into expired certificates
> (which are currently 1 year at CAcert), in a group of people that 
> communicate
> with S/Mime together. 
> With server certificates, you just exchange the certificate on the
> server, and everything is fine, so a renewal of one year isn´t so much 
> hassle there.
> But with client certs used in S/Mime it´s quite a nightmare if you depend 
> on 
> encrypted and authenticated communication within a group.
> So I would suggest that we change the lifetime for assured client
> certificates to 2 years as well.

Ok, reasonable. Again, my main concern is with secure servers.
Personally,
I use other mechanisms (GPG, OTR, SILC, or just passwords) for
everything 
that requires peer to peer authentication, so whatever you guys decide
to 
do with client, code, etc certificates should be considered outside of 
what I am proposing.
 
> > 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.
> 
> Yes, that is a goal.

Excellent! Here's to guy guys achieving it then! Cheers! :)

> > 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. 
> 
> I think it´s too complex that way.

Agreed, in the long run software should ship with CAcert
root certificates. But if everyone is installing these 
things manually anyways (especially browser developers,
they are motivated by circumstance too), you guys have a
lot more pull. Especially if your methods for authenticating
domains independent of ID are sound.
 
> > 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.
> 
> There are already ways like TTP to solve that problem.
> If you can´t find a solution there yourself, I would sugget 
> you contact our support people, and tell them that you would 
> like to get assured, but you can´t find a way to get that 
> done yourself.

Well, consider me a anonymaterian in this step. I reject the
request to present ID as much as vegetarians reject meals that 
involve meat :). I am willing to put up with *some* short term 
hassle, so long as eventually the system converges on trusting 
my domains long-term. I also think this is key to servers adopting 
you, so I believe it is in both our interests to behave this way.

If ultimately the browsers refuse to accept CAcert because of
sponsorship by verisign, thawte, etc (hey, it is possible, they
will likely go to great lengths to protect their oligopoly -
including throwing large sponsorship $$ at open source browsers,
or even commercial ones),  at least cacert has the option of winning 
mindshare via every site that says "Hey, just go here to install 
the cacert root cert, and then all these annoying popups go away 
for a ton of sites. You can verify this is the real root cacert 
via this signature mechanism: <insert appropriate procedure here>." 

Someone can even pay verisign to sign an SSL site 
that hosts cacert.org's root cert on it. That would be a great 
publicity stunt to force their hand in revoking that cert 
to prevent adoption (yes, I am both paranoid and ruthless ;)
-- 
  
  
mfolimun AT elitemail.org

-- 
http://www.fastmail.fm - Accessible with your email software
                          or over the web