Policy-Discussion

[Philipp Gühring <pg AT futureware.at>]

Hi,

> > 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.. :(

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.

> 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.

One feature I am personally missing from the GPG web of trust is the question 
of the meaning of the signatures. I am still waiting for the first 
[RFC compliant] CPS of a GPG user. Without that the GPG web of trust is a bit 
meanlingless to me.

> > (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. 

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.

> 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. 

Some browsers and vendors did that already, but the major ones (Mozilla, 
Microsoft, ...) won´t do it that way.

> 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.

CAcert is offering lots of different kinds of certificates:
It offers server certificates for SSL, client certificate for SSL, S/Mime, 
Codesigning and openPGP Signatures
It offers unassured and assured certificates
It offers class1 and class3 certificates
It offers personalized and anonymous and even anonymized certificates.

There are a lot of different applications out there that have very different 
demands for CAcert´s certificates. 

CAcert is trying to provide certificates for different needs and applications.


Why some certificates last 6 months and others 1 or 2 years has several, 
partly historic reasons. Duane explained it several months ago on this 
mailinglist:
---------------------------------
> Client certificates expire after 730 days (= 2 years) for assured people,
> and after 180 days (= 6 months) for unassured people. 
> Server certificates expire after 365 days (= 1 year).

This doesn't follow current policy, and I was hoping you were going to 
post a correction email.

Current policy is:

Client certificates are always 365 days, server certificates are 180 or 730.

The reasons for the ways things are is because:

Servers are usually more secured which is why we allow up to 2 years, 
however to encourage people to become assured we limit them to 6 months, 
and because Thawte issued cli certs for 12 months regardless of status 
it was felt we had to as well or people would simply go "Why would I 
only want to get a 6 month certificate".

I personally see no reason to change anything, most desktops are less 
secure, but the downside to reducing certificate length is adding 
annoyance to the user to keep coming back to get a new cert which may 
still act as a disincentive to get new users.
-----------------------------



> 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.

> 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?


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.


> 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.

The name of the individual is encoded in the CommonName for client 
certificates. (And not encoded in server certificates, as far as I remember, 
since we haven´t found any useful fields for that in X.509. If you find them, 
let me know)

> > 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?

CAcert isn´t providing pseudonymous certificates in general at the moment.
One exception is that CAcert is offering certificates to artists in germany 
for governmental registered artist names.
Another thing is that Organisations can choose the name for the 
organisational 
certificates, so they could use pseudonyms there, but still the official 
organisation name is written in the certificate.
But CAcert doesn´t have a generic concept for real pseudonyms yet.
One request for the approval of an (invented) artist birthday was denied.

I heard that pseudonym certificates are a common concept in germany, but they 
way they are doing it didn´t sound secure and reasonable to me, it sounded 
more like a hack to circumvent the wrong identity concept they had. But I 
might be wrong, so if anyone has a good concept for pseudonymous 
certificates, let me know.

> > 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.

Well, that could have an application in high-security environments. 
But I doubt that CAcert will be used in high-security environments in the 
near 
future.

> 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.

> 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.

> 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.

Well, the big problem I see there is the Webservers, it´s security, it´s 
workflows and it´s usability. I think we will have to start working on that 
problem

> 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.

> 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,  

It´s a bit too complex for easy judgements :)

> but hey 
> it's not my decision).

You can change that, we still have open positions for the X.509 product 
managers:
http://wiki.cacert.org/wiki/ProductManagers

Best regards,
Philipp Gühring