On 11/10/2008 02:11 AM, Kyle Hamilton:
On Sun, Nov 9, 2008 at 7:26 AM, Eddy Nigg<[EMAIL PROTECTED]> wrote:
Since there's a fairly argumentative tone going on, I think I should
explain what my viewpoint is:
Kyle, your reply was highly interesting! Nevertheless I'll cut down my
response to a few highlights only... (after writing my reply I realized
that's more than expected).
1) I believe that users who own their own machines are sovereign. The
USER, not the CA, is the root of all trust on that user's machine.
In principal I agree with this statement and I believe this is in fact
the case.
2) I believe that CAs which have been audited against their CPs and
CPSes have a severe disincentive against making new types of
certificates available....
I agree with most if not all points up to here...
6) I believe that the USA has a chartered requirement to not infringe
on anyone's right of free association.
I don't think that anything prevents you from doing so.
7) Because of #1, I believe that users have the right to use their
computers as tools they can work in any manner, for communications
they wish to share in any manner, and with pseudonyms as they may
require or desire -- not simply with the de facto legal identity
information embedded in ways that CAs currently require. Also because
of #1, I believe that assigning "ultimate trust" to any CA that is not
run according to the need of the user is a violation of the user's
sovereignity.
You have the freedom to embed your own CA, remove existing CAs etc.
Nobody violates the users sovereignty if he cares. Also ways exists
(mainly domain/email validated certificates) without really having to
disclose who you are publicly.
However the same right also exists for the software vendor who has the
freedom to decide what's in the best interest of the average user. Also
its own interests are legitimate up to a certain extend (depending on
the position in the market and other factors).
10) However, the dominant
paradigm of cryptographically binding an identity to a key (but only
as long as the identity that's bound is the legal identity) makes it
difficult for advocates of cryptography to gain any traction in those
environments.
[EMAIL PROTECTED] is hardly a legal identity...
By trying to appear 'legitimate' the authority which you created falls
into the same problems which plague every other authority.
I don't sense the problem really.
As well,
since the 'authority' that you run does not issue the credentials
which can be used to authenticate a legal identity, your 'authority'
is not 'authoritative'.
Doesn't this depend on the type of verification done? I agree that CAs
resemble much more a Notary Public than the authority governing the real
legal identities.
but a general-purpose certificate issuer is only
authoritative on 'the entities which have chosen to request issuance
of a certificate from it'
Obviously. Nobody forces anybody into it.
What I do have issue with, though, is that you seem to think that the
service you created is a panacea
No it's not. As I stated - besides being legitimate and similar - we
provide an alternative and remove the financial barrier. This is a big
hurdle for many still which prevents adoption by the masses of
(legitimate) digital certificates (not the only one, but one of them -
ease of use is another one).
that the concept of monetary
exchange is the only thing which prevents people from using the
services of the general-purpose CAs. It's not.
Of course not. But I can't serve you otherwise. But we should recognize
that the context we are discussing here is hundreds of millions of users
(of the browser), potentially millions of web sites, a handful of CAs
and a few browsers. There are various goals we try to achieve with PKI,
starting from preventing eavesdropping, reliance (mainly for business
purpose?), prevent fraud (phishing) if possible etc. In this context,
PKI makes a lot of sense...it may not for your (other) alternative
networks, affiliations and software.
(Among other things,
you issue end-user certificates, which cannot themselves issue other
certificates.
Of course not. Would be the same as "self-authorized".
This means that a user cannot use the certificate you
issue to issue certificates to his router, his PC, to his friends, to
any services that he chooses to run -- all he can issue are proxy
certificates, which cannot be used for identity; they can only be used
for delegation of the permission that an end-user certificate has.
Since end-user certificates cannot be used to identify servers, the
end-user still has an artificial barrier to entry if he wants to, say,
protect his home network with ipsec.)
Mmmhh...can you explain that again? Get the right certificate for the
right purpose then...nothing prevents you from doing that.
and the fact that there is no centrally-searchable
database is what allows for certificates to be mis-issued by audited
and trusted CAs, under the strict readings of their CPs.
I don't understand which misuse you refer to. However strict reading of
CPs sounds good to me ;-)
I agree, this characterization is far too simple. I just want to
maintain the ability for users to reason their ways through the
process of adding new roots to their stores. I would like to simplify
this process as much as possible.
Kyle! It's easier to add a CA root to your store than add an exception
for a self-authorized certificate. Did you try? Try for example this
link: http://www.startssl.com/?app=9
1) A certificate should not be self-signed if it is being used to
identify a server, as a means of encouraging best-practice CA key
management.
I'd sign on that :-)
2) If a certificate issued by a CA and a known CA have the same key,
the certificate should be flagged for review (again, encourage
best-practice CA key management).
Indeed...that actually should never happen.
4) There should be an extension defined in CA and end-entity
certificates for a CA to embed information on how to add the CA to the
trusted store. (There's already two extensions defined for CAs to
link to their certification practice statements, but none for any
tutorials or information on how to add a CA to the root store.)
Many have that. It's in the CA Issuer entry of the AIA extension. For
example examine the intermediate CA certificate of
http://www.startssl.com/certs/sub.class1.server.ca.crt
5) The security exception dialog (even if it's not an actual dialog
box, it's still an interaction between the user and software) should
also have a prominent link to the criteria for inclusion in the
default NSS database, and those criteria should have their rationale
explained
Even though an overkill, this is actually a nice idea. Something like
this should be maybe made available through the UI (web site information
dialog via Larry). Obviously I wouldn't promote an exception for
correctly secured sites.
so that the user has the ability to understand what
exactly is at stake.
Again, 99.9% of the users will never see nor understand it.
As well, there should be a statement "Mozilla,
Firefox, and NSS take no responsibility for any consequences which may
happen if you add a CA that they have not included."
So you want to make it harder to import a new root into the browser?
You don't have to search a lot....just visit Paypal and look at your
browser. That's the way the wind is blowing. And if regular certificates are
further circumvented and devalued, this is what you'll be left with in the
end. Think about it!
Er, honestly? "regular certificates" have already been devalued by
the entry of over 100 competitors to Verisign.
> The fact is, "regular certificates" didn't go far enough. The idea of
> domain-validated certificates was created by an audited and accepted
> CA, and that idea appears to me to be what led to the creation of the
> EV certificate profile by the CAB forum anyway.
You maybe misunderstood. I'm in favor of domain validated certificates,
they serve a legitimate purpose if applied correctly. What I meant is,
that if DV (and otherwise validated) certificates are further devalued
by various means (including self-authorized certificates) and the only
way to rely on digital certification is by the means of EV, than the
trend is clearly that support for DV will be dropped at some point by
the browser and CA alliance.
I removed my trust in
Firefox for every CA that I could find a CPS for which suggested that
they could issue domain-validated certificates,
Aren't you contradicting yourself? Remove support of domain validated
but promote self validated certs?
and I found that the
browser's chrome made it impossible for me to get anything done after
I did that.
If you removed the StartCom root, than you deserve to be punished ;-)
I brought up the additional cost for EV certificates before; you
thought it wasn't appropriate for me to bring up because "only major
e-commerce sites and banks" would need them. And now, you seem to
suggest that eventually, it likely will end up that everyone who
touches credit card numbers or other fiduciary data will need an EV
cert anyway?
I'm saying that those are the trends! I didn't say anywhere that I
promoted it nor was in favor of it!
AFAICT, it's only really banks and other
fiduciaries that need the EV protection.
Well, I value private information worthy to protect even more than
credit cards (besides the hassle). Sharing information may be more
critical and it's good to know with whom you share it.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: [EMAIL PROTECTED]
Blog: https://blog.startcom.org
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
