Policy-Discussion

["Peter Williams" <home_pw AT msn.com>]

If it helps I own some high end FIPS140-1 level 3 hardware that other CAs
have used as the "control apparatus" for roots. The units' assurances, even
when the root keys (once "controlled") are stored offline in PCMCIA cards in
NL, and are removed from on the flash within the cryptomodules. This would
likely be incredibly useful for audit.

I get the feeling CAcert isover the hump on resisting the thrust of what
audit is about (transparency), and is now down to minimum controls on
certain critical components. Where machines do the work, things get easier
-especially if the machine has already been audited as "properly
controlling"

-----Original Message-----
From: 
cacert-policy-bounces AT lists.cacert.org
[mailto:cacert-policy-bounces AT lists.cacert.org]
 On Behalf Of IanG
Sent: Saturday, October 25, 2008 5:24 AM
To: Policy-Discussion
Subject: Re: [CAcert-Policy] Why I switched to a thawte certificate

Hi Sven,



Sven Anderson wrote:
> Hi,
> 
> I didn't read on this list since a long time, so I apologize if this has
> been discussed before.


I think it is always useful to see individual testimonies, it gives
us perspectives from the coalface.

> I stopped using my CAcert certificate and use a free thawte certificate
> now. That is sad, I know. So why did I switch?
> 
> 1. Usability. I stopped signing my mails by default a while ago, because
> some people complained and some even claimed I have a virus (sic!). This
> is an weird result of the very stupid fact that mail clients warn about
> mails signed by certificates of an unknown CA, although they are not
> more dangerous than unsigned mails, which obviously don't result in a
> warning. Until CAcert is not in the root-chain, this will not change.


That's an audit question, I perceive.  You can see progress about
this here:  https://wiki.cacert.org/wiki/AuditPresentations

Recent news:      Systems were moved to NL.  New team in place.
Next steps:       CPS is blocked on the email/domain issue.
Always reminder:  audit work is done by the community, so if you
have a complaint, it is about yourself :)  See previous point.

There will be a fuller report to the AGM coming up 7th.


> 2. I don't need "identity". I want confidentiality (encryption),
> communication coherence (do I talk to the same person as yesterday?) and
> _sometimes_ trust. But trust in real life is never build upon identity.
> I trust people because I "know" them. And "know" in this case means
> either a good personal experience or a good reputation by somebody else
> I trust.


I agree with all this, and indeed, so does CAcert.  Three points:

1.  CAcert has always issued certs without Names, for both of the
old roots.  This is likely to continue, in principle.

2.  CAcert has now moved to detune the Identity issue with its new
Assurance Policy (in DRAFT) here:

http://svn.cacert.org/CAcert/Policies/AssurancePolicy.html#1.1

Have a very careful read of 1.1.  What is now important to CAcert is
listed there.  Name is only one element of this.

Now go back to point 1 above and you will see that these two align.
CAcert's certificates are as good with or without the Name.

So the end result of this is:

   If you need Identity, it is there.
   If you don't need Identity, you don't have to use it.

(Explaining this further will take pages and pages, or it did when I
tried to do it last week for somewhere else.  Hence here, I will
chop it short, apologies.)

3.  The CA world is obsessed about Identity.  For this reason,
although it is possible to craft good solutions without Identity,
CAcert needs to void drifting too far from the CA status quo, unless
it wants to reinvent the browser.


> (Now you will say: fine, use PGP and it's WoT, it's made for
> exactly this. Right, but here comes usability into play again. S/MIME is
> included in every mail client, PGP is not.)


OpenPGP is an answer but it is very unsatisfactory to say that this
tool does it how I want it, and this other tool does it how they
want it.  In a perfect world, CAcert should be working to
incorporate the best of both tools together.  See above.


> So, I can have a very
> trustful relationship with people whose identity I don't know. In fact I
> never saw the IDs of most of my best friends. So I don't care if there
> is my real name in the certificate or not, and for some things I even
> don't want it. That the certificate belongs to a certain mail address is
> all I need, and this can be automatically verified by any CA. In a
> situation, in which I really need the identity - because I want to make
> business with an unknown person for instance - I will not trust the data
> inside a certificate anyway, because it's only as secure as the weakest
> CA in my root chain. And that's really not enough. I would always verify
> the information out of band.


This is your fundamental view of trust, as opposed to the "trust
product" that is sometimes touted.  However, whatever you think
about the world of humans, CAs have to work to the constructed world
of CAs.  So, CAcert has to dance between your trust reality and a
bunch of criteria that says "do it this way."


> Why do I tell you this on the policy list? Well, I would happily come
> back to using CAcert, if I could get a certificate which does only
> contain my mail address, but whose CA is included in the client's root
> chains. What I want to propose is a fast track approach for "browser
> inclusion" by introducing a complementary CA to the class 3 CA of
> CAcert, that is a CA for anonymous (email-address based) certificates
> only. I assume that the inclusion of a CA, that is only based on
> automatically verified data, will be a lot easier and faster to get
> included into the root chains. If you can include the class 3 CA later
> as well that's great, but at least CAcert can offer the same as thawte
> in the meantime.


Something like that is indeed under discussion.  This business
question has been discussed internally because since the audit
project was started, the browser world has changed, and quite
dramatically.  There are now two tracks forward into the browsers.
Allied to this is a growing realisation at the vendors that imposing
high standards for everything resulted in adverse results because
the real result was low standards regardless of that imposed.

For various reasons, the analysis of the situation leads to a
fast(er) track solution similar to yours, but with the preference
for Assured Individuals rather than unassured.  It achieves the same
effect for you.  The reason for preferring the Assured path is that
it is less sensitive to the current CPS blockages (written about
extensively elsewhere), and the board has proposed that whatever
track is chosen, CAcert's standards are to remain high.

That is, unassured Members won't have an audited solution as
quickly.  Also note that the fast track solution will likely not
come as quickly for OA, because there are substantial open questions
there, too.

Next steps:  Hopefully someone will move to propose something on the
email/domain checking question soon.



iang

_______________________________________________
Have you passed the Assurer Challenge yet?
http://wiki.cacert.org/wiki/AssurerChallenge

CAcert-Policy mailing list
CAcert-Policy AT lists.cacert.org
https://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy