- I believe that having more CAs in the world is an inevitability. - I believe that restricting which CAs are allowed to embed their root certificates beyond purely technical/interoperability concerns is counterproductive.
I don't agree completely - in fact, I support the requirements of point 6 of the policy.
- I believe that the current models that are used for determining how CAs behave are broken, and have inhibited the adoption of cryptography beyond merely the financial realm.
By "current models", are you talking about CPSes?
- People involved in a financial transaction are required to collect a
certain amount of information about each other -- running the gamut from
"the money's good" for cash transactions, to the verification that the
person giving a given CC number actually owns it ("the card verification
code matches", or as brick&mortar merchants were originally required to do,
"verify that the signature matches").
Suggested corollary: any certificates involved, being the only means by which one party can identify the other, must contain or provide a method to obtain all the information one might want to obtain for any form of transaction carried out under it.
So, what I would propose is 'warn the user when submitting a form to a site
secured by a CA that does not provide for proper identity in its CPS, and
audited by (for example) the WebTrust auditing process.'
I agree that the UI should differentiate between CAs which do not establish proper identity and those that do, but given that we don't warn for forms submitted over insecure channels (well, we do, but everyone turns it off after the first time) I don't think a warning box is the right UI.
(Thawte's CPS states that they will only issue web-server certificates to entities with High Assurance of identity. Thawte has recently started issuing, from the same root, certificates to entities with merely web address verification, through its SSL123 program -- I will assume that you all know this, and move on.)
Just out of interest, does WebTrust have a process for complaining that a CA has violated its CPS?
Now. As I said before, I'm all for the idea of alternate CAs, and I am all
for certificates being issued based on information available to those
alternate CAs. I believe that membership organizations (and even websites
with forums and such) should run their own CAs, issuing certificates to
people who prove possession of access credentials to accounts within those
realms. These CAs should /not/ be trusted for financial transactions,
because they don't prove fiscal identity... and eventually I'd like to see a
user-interface change in all browsers where the lock icon is joined by some
kind of 'fiscal verification' icon when the certificate is issued by an
audited fiscal CA in accordance with its CPS.
I definitely agree that we need to split the two categories apart with some sort of UI indication.
Strike:
- cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists.
Rationale: The latter is for those who have operational issues with CRL or OCSP services, decide to take them down, and no longer issue certificates with those extensions embedded... but do not revoke prior certificates with those extensions embedded. I may have missed some discussion on this topic. (The CA certificate, itself, may be presented with OCSP/CRL information, and then have it taken down for some reason. If that's the case, the CA certificate can't really change.)
If you are standing up and saying that you only issue certs to organisations you have verified the identity of, you need to provide a way to fix your mistakes.
I believe that if a CA has the 'fiscal verification' icon you allude to, they should be required to only issue certs which have URLs to working OCSP servers embedded in them.
Gerv _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
