Policy-Discussion

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

Hi,

> Hrmm.. If these archives were public & searchable, perhaps I could find
> this easier? :)

http://lists.cacert.org/
just download the mbox files and import into your email client.


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

Hmm, demanding something like 2 out of 3 verification mechanisms? 
Hmm, sounds like an interesting idea.
Ok, can you develop a full proposal (including the technical details) for 
that?

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

Yes, but not so good for our currentl software development ressources. But if 
you provide us a patch that does it as well, the chances might be better.

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

We would have to implement a non-caching DNS resolver on our side

> where as finding an assurer and meeting them can take weeks, or even
> months.

Well, we can´t compare apples and bananes here.


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

Why don´t you automate it? CAcert has a nice API for that ... 
I am really wondering that the Webserver developers are still delivering 
software to their users that can´t automatically renew a certificate.

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

Hmm, no, that´s a bit too much.

> Ok, reasonable. Again, my main concern is with secure servers.

Ah, so you are interested in becoming the Server-certificate Product manager? 


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

Most vendors haven´t shown much interest in the details of our practices

> Well, consider me a anonymaterian in this step. I reject the
> request to present ID as much as vegetarians reject meals that
> involve meat :).

What for do you have it in the first place, if you reject to present it?
Which parts of your ID do you classify as secret, as reasoning for rejecting 
the presentation of the whole ID?

> I am willing to put up with *some* short term 
> hassle, so long as eventually the system converges on trusting
> my domains long-term. 

Ok, then invest some time into automating the renewal of the certificates.

> I also think this is key to servers adopting 
> you, so I believe it is in both our interests to behave this way.

Yes, a far better usability for the webservers is key to adoption of HTTPS.

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

How many sites have you convinced to do that yet?

> 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 ;)

Yes! Could you buy us an EV cert from Verisign please?
I´ll send you the CSR for it, ok?

Best regards,
Philipp Gühring