In my previous posts I announced adoption of the new Mozilla policy on CA certificates and discussed the CA market and possible roles for CAs. In this post I present some of my personal thoughts about how the SSL/TLS UI used in Firefox and related products might evolve, based on past discussions in the n.p.m.crypto and n.p.m.security newsgroups and conversations I’ve had at different times with various CAs and browser suppliers.
Note that this post represents my personal opinions only. I personally don’t have any control over the SSL/TLS UI in Firefox or other Mozilla software; my role is limited to offering suggestions. Questions about or proposals for features in future releases of Firefox and other Mozilla-related software should be directed to the Firefox developers or the other project teams.
Proposed security goals
In a comment to my post on the “business of CAs” Ian Grigg raised the reasonable point that I discussed the goals and motivations of CAs but didn’t really address the question of what the Mozilla project’s goals are. I took the approach that I did because before discussing Mozilla project goals relating to security and certificates and how to achieve them, I first wanted to address the question of the environment in which CAs operate and how it might evolve. In my opinion it makes no sense to make policy and implement features in a context where the proposed policy and features might not make sense. In particular, if we decide to make plans that call for CAs to play a particular role then we have to have some reasonable degree of assurance that they will actually play that role.
So now that I’ve discussed what CAs might do and might want, what do we (the Mozilla project) want? I propose two basic security goals for Firefox and other Mozilla projects in relation to PKI features:
Provide users with the means by which they can have a reasonable assurance of end-to-end confidentiality and integrity for their Internet transactions, including browsing to SSL/TLS-enabled web sites, connecting to other SSL/TLS-enabled Internet servers (e.g., to send or receive email), and sending and receiving individual signed and encrypted email messages.
Provide users with the means by which they can detect and deter phishing and related attacks which rely on tricking users into taking actions harmful to themselves (e.g., entering their personal information on phishing web sites, or downloading and installing malicious software).
Implementation approach for assuring confidentiality and integrity
In my opinion the first goal can be (and for the most past has been) achieved through a combination of
the use of certificates issued by CAs that at a minimum validate ownership of domains and email accounts (in other words, CAs operating at least according to the “fix DNS” view of what CAs should do);
the NSS/PSM support for extracting the domain name or email address from a certificate and cross-checking it against the web site requested by the user (for an SSL/TLS-enabled site) or the email address in the “From header (for an S/MIME signed email message);
the existing Firefox SSL/TLS UI and Thunderbird S/MIME UI, including the Firefox status bar display of the validated domain name for a site; and
the recently-adopted CA certificate policy that requires validation of domain name or email account ownership as a condition of including a CA’s certificate into the pre-loaded list of CA certificates.
Implementation approach for using PKI to deter other attacks
What about the second goal? In general the scope of the phishing problem is well beyond what CAs and certificates can address (in large part because SSL/TLS is not used with most current phishing sites). However it’s possible that CAs and certificates can play a role in protecting against phishing that is complementary to other schemes that have been proposed (e.g., anti-phishing blacklists, petnames, security skins, and so on). (In this regard it’s also worth highlighting the variety of Firefox extensions that already exist in this space, including the Netcraft toolbar, Amir Herzberg’s TrustBar, and Tyler Close’s petname extension.)
As with the first goal, a suitable approach must combine elements of CA practices, UI, underlying PKI-related code features, and policy; one possible approach is as follows:
CAs could offer new “extended validation” (or “enhanced validation”) certificates issued according to a more rigorous and documented set of guidelines as to how certificate applicants might be vetted. (Note that I use the term “extended validation”—not a term I invented, but one that I like—rather than “high assurance” to differentiate the new certificates from current certificate offerings that are advertised as “high assurance” but for which the exact nature of subscriber validation is not fully known or is not common across CAs.) These certificates could be used in the context of connections to SSL/TLS-enabled web sites, sending and receiving signed email messages, and downloading and installing executable code.
The UI for Firefox and related products, especially the SSL/TLS UI, could be enhanced to visually differentiate web pages retrieved using connections for which extended validation server certificates are used, as well as to provide additional information potentially useful to users, such as the (presumably validated) name of the organization and individual operating the web site and possibly the name of the CA that issued the certificate. (A similar approach could be taken to the UI for signed email or downloadable code objects, displaying the validated name of the entity sending the email message or distributing the executable code.)
Code underlying the UI could support marking CAs and certificate products for which extended validation was done and identifying at run time whether a certificate presented was associated with extended validation or not (in other words, what types of information within the certificate would be treated as valid for purposes of the UI).
The Mozilla CA certificate policy could outline the criteria for considering a particular CA and its certificate offering(s) to be consider as having extended validation, ideally by referring to some independent set of criteria (comparable to the criteria we currently reference in the Mozilla CA certificate policy) along with a process by which CAs can be audited by third parties as to whether they meet such criteria.
In subsequent sections I discuss each of the elements of this approach.
Prospects for extended validation certificates
For a while now Gerv Markham and I have been talking informally with others about the topics of commercial CA practices and the browser UI associated with SSL/TLS connections. While I can justify having some private discussions with various parties on matters of mutual interest, I think it’s now well past time to have a more public discussion of these issues, a point with which at least some others involved in the discussions (especially the browser suppliers) appear to agree. Last week I was in Toronto, Canada, for a meeting with people from Microsoft, Opera Software, and the KDE project. These discussions motivated me to write this series of CA-related blog posts, and others have published their own comments as noted below.
Based on discussions I’ve had in the past, I think that many CAs would like to see browsers give different UI treatment to CAs and certificates for which more validation of certificate holders is done. Some CAs have apparently held on to the hope that browser suppliers would simply bless their existing “high assurance” certificate products as worthy of special treatment. I personally think that this hope is in vain, due to the ill-defined and not-fully-documented nature of many CA’s practices, even for “high assurance” certificates.
I don’t have time to evaluate each and every CA’s practices and make a judgement on their claims that their certificates are really “high assurance,” in the absence of some external reference document that defines that term and the practices associated with it. I believe that people at at least some other browser suppliers feel likewise, and also want to see some independent set of criteria created.
The question then becomes: Is creation of an independent reference likely to happen and, if so, how will it happen: What is the process? Who will do the work? Under which organizational auspices will it be done? And so on.
One possibility is for a group like the Information Security Committee of the American Bar Association to suggest guidelines for the due diligence that CAs should undertake prior to issuing extended validation certificates, building on existing commercial practices used to validate business and personal identity off-line. Among other things, the ISC was responsible for creating the PKI Assessment Guidelines that were used in creating the WebTrust criteria, so it does have a track record of work in this area. The ABA is of course a US-centric organization, so any proposals by the ISC (or any other US-only group) would also have to be validated in other countries with different legal systems.
Other possibilities (not mutually exclusive) are for the ABA ISC work to serve as a starting point for a standards effort pursued through a formal standards organization like OASIS or the W3C, for the work to be incorporated into a new version of the WebTrust criteria, or for CAs themselves to work together on this through some sort of informal or formal CA industry group. I don’t have strong opinions as to what exactly should happen, or whether the resulting work should be in the form of a “standard” as opposed to “guidelines.”
Will CAs work together to help all of this come to pass? I honestly don’t know; there are clear differences among the CAs I’ve talked to as to how they want to approach the problem of cross-CA guidelines and standards, or whether indeed they want to do this at all. However I do suspect that most if not all browser suppliers will be unlikely to make major modifications to their certificate- and CA-related UIs (e.g., the SSL/TLS UI) in the absence of independent efforts to define a set of CA practices that can support the proposed “extended validation” certificates.
Changing the SSL/TLS UI
In the past we’ve discussed ways to change the Firefox SSL/TLS UI in order to take into account possible differences among certificates. Ideas proposed have included adding a second padlock or another icon (e.g., a dollar sign) to mark the use of extended validation certificates, or reserving the padlock only for extended validation certificates and “demoting” existing certificates to use some other icon. Gerv Markham has written on this topic, but I’ll wait until Gerv gets back from vacation to comment on his ideas, since he’s not online and able to respond to comments.
In the meantime Rob Franco and others from Microsoft have proposed a new IE7 SSL/TLS UI for use with any future extended validation certificates. Their proposal incorporates the following ideas:
The padlock icon would continue to be used for all pages retrieved using SSL/TLS connections, no matter the type of server certificate presented.
For extended validation certificates the (presumably validated) name of the web site operator would be displayed next to the padlock icon. This display would periodically alternate with display of the name of the CA that issued the certificate.
For extended validation certificates the background color of the location bar would be changed to green, as opposed to white for other SSL/TLS pages. (IE never adopted the convention—used in Firefox and other browsers—of displaying a yellow background for pages retrieved using SSL or TLS; in fact, for IE7 a yellow background would be associated with a site identified by the IE7 phishing filter as a possible phishing site.)
I’ll leave it to others to write a more detailed critique of this proposal; for now I just wanted to note a couple of things:
Microsoft proposes leaving the existing SSL/TLS UI as-is for all existing certificates that do not conform to the hypothetical new extended validation requirements. I agree with this approach.
In Microsoft’s proposal the UI elements used for distinguishing different types of certificates and displaying certificate-related error are also used for alerting the user to potential phishing attacks. (For example, the red background color in the location bar is used both for phishing sites and for sites with self-signed certificates or certificates from unknown issuers.) In other words, Microsoft is treating the security protection afforded by PKI features as simply one component in the overall protections provided against on-line fraud. While I might quibble with some of the details, I think this is a worthwhile approach.
Microsoft’s proposal provides more visibility for the CA issuing an extended validation certificate than is present in most current browsers (which to display the CA name typically require an extra user action like clicking on the lock icon or moving the cursor over it). Besides making users more aware of the role of CAs, this provides CAs with an opportunity to do the sort of brand-building mentioned in my previous post, and to that extent offers an incentive for CAs to participate in the market for extended validation certificates.
For other views of this proposal, see the recent KDE.news article by George Staikos of the KDE project and a separate article by Carsten Fischer and Yngve Pettersen of Opera Software. For my part I think this proposal is worth studying by the members of the Firefox developer team concerned with the location bar UI, as well as by anyone implementing Firefox extensions to support anti-phishing toolbars and similar security UI enhancements.
Detecting and using extended validation certificates
As noted previously, any new UI proposal has to be supported by underlying code to support marking CAs offering extended validation certificates (as defined by whatever policy we might adopt) and detecting use of those extended validation certificates at runtime. I’m by no means an expert in the details of X.509v3 certificates, so I’ll refrain from making any truly technical comments. However I will note the following issues and suggestions, based on my conversations with people from other browser suppliers and within the Mozilla project, people much smarter than I am about these issues.
First, we can’t simply mark a given root CA as issuing extended validation certificates or not. For example, it’s perfectly conceivable that a CA might have two different subordinate CAs, one of which issues extended validation certificates and one of which does not. It’s also conceivable that a CA might directly issue extended validation certificates and other certificates under the same root CA (just as some CAs today directly issue “domain validated” and “identity validated” certificates using the same root CA.)
Some CAs today distinguish different classes of certificates using relatively ad hoc techniques; for example, a CA might set the Organization (O) field in a certificate to the certificate subscriber’s organization name for a “high assurance” certificate, and to a special value like “*Domain Validated*” for a “low assurance” certificate. However this also isn’t suitable as a general solution; it’s not feasible to implement special heuristics to recognize each CA’s idiosyncratic ways of marking certificates. (This is also one of the many reasons why I think it’s fruitless to try to implement an extended validation UI on top of today’s certificate offerings.)
Thus we have to find another way to mark extended validation certificates and CAs that issue them. One obvious mechanism is to use the X.509v3 Certificate Policies extension (defined in section 4.2.1.5 of RFC 3280 and described in more detail in section 3.1.1 of RFC 3647), which specifies one or more “object identifiers” (OIDs) identifying the policy or policies under which a certificate was issued. One possibility would be to have a single universal “policy OID” that corresponded to an extended validation policy; however this is inflexible—a policy OID should refer to a single invariant policy document, and we can’t expect all CAs to use the exact same document..
One alternative to a universal extended validation policy OID would be to allow CAs to assign whatever policy OIDs they wish, corresponding to the specific certificate policy or policies under which they issue certificates. If some of these policies corresponded to extended validation policies (as determined by independent criteria and attested to by independent auditors), then the policy OIDs for those policies could be stored as metadata associated with the root CA certificate, i.e., as a supplement to the pre-loaded root CA certificate list. The (greatly somewhat simplified) algorithm for recognizing an extended validation certificate would then be as follows:
For a given certificate, look for the presence of a Certificate Policies extension and extract the policy OID value(s).Go through the “certificate chain” (i.e., the list of certificates containing the “end entity” certificate itself, the certificate of the CA that issued it, the certificate of the higher-level CA that issued that CA’s certificate, and so on) and process it according to RFC 3280.At the end of the processing step we will have a set of zero or more certificate policy OIDs as specified by Certificate Policy extensions present on either the end entity certificate or the CA certificates of any intermediate certificates on the chain.
Compare the policy OID(s) to the list of extended validation policy OIDs associated with the CA.
a. If one or more of the policy OIDs
for the certificatefrom the certificate chain is on the list then we can treat the certificate as an extended validation certificate (including displaying a modified UI).b. Otherwise treat the certificate as a “normal” certificate and display the traditional UI.
There are some subtleties that I’ve ignored, most notably what happens in the case where certificates are issued by subordinate CAs instead of directly under the root how policy OIDs associated with Certificate Policy extensions on an intermediate CA certificate interact with with policy OIDs set by Certificate Policy extensions on other intermedia CA certificates and the end entity certificate. I’ll leave these issues for others more knowledgeable than I to address.
Note that although the public description of Microsoft’s proposal does not define the exact mechanism by which extended validation certificates would be marked as such, as I understand it the mechanism and algorithm presented above (with refinements and corrections as necessary) is consistent with the Microsoft proposal.
Assuming that a suitable algorithm can be defined, how would support for extended validation certificates be added to Firefox and other Mozilla products? The most obvious approach for recognizing extended validation certificates would be to modify NSS to store additional metadata with the pre-loaded root CA certificates and to recognize extended validation certificates as part of the NSS code for certificate path processing and validation. Whether and when this could be done depends on the NSS development team and any other NSS-knowledgeable developers who might be able to volunteer to help design, code, and test this feature.
Assuming that NSS supports recogniation of extended validation certificates, the other major item needed is changes in the current SSL/TLS UI for Firefox. Doing this depends on the Firefox development team.
It’s possible that the UI changes for extended validation certificates or for the recognition of of extended validation certificates could and should be implemented in the form of a Firefox extension, either optional or bundled with Firefox. Again I’ll leave this question for others to address.
Updating policy to account for extended validation certificates
The final piece of the puzzle for extended validation certificates is updating the Mozilla CA certificate policy to reflect the use and special treatment of such certificates. In my opinion what is needed here is relatively straightforward:
An independent standard (or set of guidelines, if you will) that specifies the minumum acceptable business practices that CAs should follow when issuing extended validation certificates. The updated CA policy would incorporate this document or documents by reference, just as it currently does for the WebTrust criteria, ETSI TS 101 456, etc.
An acceptable process by which CAs would be audited to ensure that CAs are following the extended validation standard/guidelines. (For example, this might be added as an optional component of the WebTrust audit program.) The updated CA policy would require such an audit in order for CAs to be marked as supporting extended validation certificates (e.g., by setting optional CA metadata as discussed above).
Consensus on any other requirements we might want to impose on CAs issuing extended validation certificates. For example, we might require that CAs publish revocation information on a more frequent schedule, that they use longer key lengths for signing keys, that they be re-audited periodically, that they maintain certain types of insurance and accept a certain amount of liability, and so on.
We can make the policy requirements for issuing extended validation certificates arbitrarily complex. However each new requirement puts more burden on us to verify a CA’s compliance, potentially raises the price of extended validation certificates to those sites wishing to use them, and also is a potential barrier to entry to CAs wishing to enter the market for extended validation certificates. We therefore need to ensure that any new requirements are actually justifiable in terms of increasing the security of typical users, and are not being added primarily for the sake of appearances—in other words, the same approach we tried to follow in creating the current CA certificate policy.
A final note: In this post I focused mainly on the SSL/TLS UI in browsers. However much of this discussion applies to other contexts, in particular viewing signed email and downloading executable code objects. For example, Thunderbird might recognize the use of an extended validation certificate in association with a signed email message and modify the appropriate UI accordingly (e.g., display the validated identity of the signer on a green background, if we wish to adopt the Microsoft proposal).
Similar comments apply to the UI for downloading executable code objects; in fact, we might even want to require that downloadable code be signed using a private key associated with an extended validation certificate. This is especially true given that with downloadable code objects the subscriber information in the certificate is pretty much the only information the user has to evaluate the software publisher; there is no mechanism to cross-check certificate information against other data as there is with browsing (cross-checking against the domain name of the server) or with email (cross-checking against the “From” address).
With that I’ll conclude this post, and perhaps take at least a temporary vacation from blogging about CAs and certificates. Thanks again for your patience if you’ve read this far.
UPDATE: Changed the link X.509v3 certificates to point to RFC 3280 instead of RFC 2459 (which it superceded), and clarified that the Certificate Policies extension is first defined in RFC 3280. Added a new revision of the WebTrust criteria as another possibility for a common reference document for CA practices related to extended validation certificates. Corrected the specification of the sample algorithm for determining whether a certificate was an extended validation certificate or not.