Following discussions both in private and at the dev-security mailing
list of Mozilla with various participants, we decided to put forward the
following initial proposal of a framework for the handling of SSL/TLS
and S/MIME digital certificates in Mozilla products. The trigger for
this proposal was the controversial EV standard put forward by the
CA/Browser forum, which leaded us to believe, that a more radical and
somewhat farther reaching change could serve Browser Vendors,
Certification Authorities (CA) and Relying Parties better. The basic
idea is perhaps not new and similar ideas might have been proposed
previously, however we believe, that this is long overdue.
*Introduction:*
Currently all digital certificates are treated in the same way in todays
software. A certificate is considered as valid if:
1.) The certificate is found to be issued by a CA which is in the NSS
certificate root store
2.) The certificate is not expired (Within valid boundaries of the from
/ to dates)
3.) The CN resp. emailAddress field matches the web site address, resp.
email address
4.) The certificate is not revoked (provided CRL or OCSP checking is
enabled)
If the web site, resp. signed email presents a valid certificate, a
padlock is displayed in the address bar / status bar. In all other
circumstances a warning dialog is presented to the user, which he has to
accept or deny. This includes self signed certificates, certificates
issued by an unknown CA, expired certificates. Except in case of
certificate revocation, the connection is refused. If a particular web
page is found to have unsecured content embedded, such as images or
javascript files, than a question mark / crossed padlock is placed
instead of the clear padlock.
However the browser / mail client currently can not differentiate
between different types of validations performed for the identification
of the certificate and presents all certificates in a flat way, e.g. a
padlock. This flat system exists since the first implementations of SSL
support in browsers and has never been revised. Currently it is the sole
responsibility of the issuing CA to which extend a certificate and its
holder is validated, which can vary between every CA and within a
particular CA itself, as the CA often offers various levels of
verification procedures.
More than that, any verification above simple domain validation, resp.
email validation is almost meaningless, since the low level validations
are easier to circumvent, but more thorough verifications are treaded
with the same validity. From the subscriber perspective there is almost
no reason to perform higher validation because of that and the relying
party mostly doesn't know about the extend of the validations performed.
Low level validation are effective for the intended purpose and are part
of the PKI landscape, however they are often misused for other purposes,
where really higher verification should be performed, because of the
lack to differ in its validity. This is one of the core problems in
current handling of digital certificates in todays software.
(Just a by-note, that the proposed EV standard is in many cases an
overkill and sets the mark too high for most cases. It will not solve
the problem of the current binary flat system, this in addition to other
problems about this standard.)
The Mozilla CA policy today requires a minimal set of conditions, which
a CA has to meet in order to have its root certificate embedded with the
NSS certificate root store of certification authorities. This includes a
minimal set of validations which a CA has to perform as the lowest
verification procedure. Our proposal centers around the extension of
Mozilla CA policy and aims to provide an initial basic framework for the
ability to make a distinction between different validation procedures.
Within this framework, proposed and future standards can be integrated
easily, without the need to change the behavior of the underlying
framework and its software. Based on this framework the UI of the
browsers and mail clients can be adjusted and improved in future.
*Proposal:*
We propose to define four different validation levels or classes
according to which existing and future verification procedures of CAs
can be treated. The levels could be according to the list below, however
it's only a suggestion and should be adjusted and refined after thorough
discussion by the community:
Level 1:
This is the lowest level and the current minimum requirement of the
Mozilla CA policy. Level 1 is domain validated, resp. email validated
only, for example by sending an email ping to a administrative mail
account of the domain or to the email account in question. No other
verifications are performed at this level.
Level 2:
The identity is validated by various means, such as verification of the
identity via scanned, photocopied or photographed photo ID documents
(passport, identity card, driving license) and company registry, which
is then further verified by a lookup at a third party source, such as
phone directories and phone call or sending of a registered mail to the
address found in the documents provided by the subscriber. This kind of
verification is not done in person. Ownership of the domain name, resp.
email account is performed according to Level 1. The certificate must
state the subscriber name/organization name, locality, state (where
applicable) and country.
Level 3:
Additional verifications are performed at this level in relation to
Level 2, specially verification of the provided (authentic) documents by
the subscriber, establishment of the organization (minimum years of
existents), physical address of the organization and proof of ownership
of the domain name, resp. email address. The subscriber is verified in
person by an agent of the CA or other third party. The proposed EV
certificates would most likely fall under this level. The certificate
must state the subscriber name/organization name, locality, state (where
applicable) and country.
Level 4:
Verification of the subscriber is performed in person including all
original documents. The certificate includes government issued passport
or identity card number in the OU field, in addition to subscriber name,
address, locality, state (where applicable) and country. This level is
less suited for organizations, but mostly for individuals.
*Implementation:*
The Mozilla CA policy will be extended to include the above described
definitions. Levels can be assigned by the CA within the subscriber
certificate with a specially defined OID by using for example the
Mozilla OID space. In this proposal we suggest to leave the definition
of levels to the CA, as in any case the CA defines its verification
procedures in its own policies. Implementation could be fast in this
case and CAs could be advised to assign the corresponding OID to their
certificates. For example the OID for a certain level could be:
1.3.6.1.4.1.13769.pki.mozilla_policy_version.level
The Mozilla software can search for this OID in the certificate and
accordingly provide different information to the user and handle UI
behavior. A different way of implementation could be the inclusion of
such an OID at the intermediate CA certificate level, which would
perhaps result in easier tracking between the CA policy and assigned
level. It might be easier to verify the claims made by the CA concerning
the level it assigns to the various intermediate certificates. This
would be more difficult in case the OID would be only included in the
subscriber certificate. However implementation might be slower in this
case as intermediate CA certificates are usually valid for up to ten years.
*Summary:*
This proposal provides a solution for the long overdue "binary flat
system of the padlock" in browsers for SSL certificates, without special
and unnecessary requirements on the parties involved.
- Its adoption can be promoted and implemented very fast by both the
browsers and the various CAs.
- It supports any current CA policy of all CAs in the NSS cert store.
- Any future standard - including EV - can be simply included within the
proposed structure of levels without the need to make any special
adjustments to the software.
- The liability of Mozilla will be similar to the current system,
because the responsibility of assigning and implementation of the
different level lies with the CA. However the relying party might -
pending implementations of the UI - will receive better information in
order to make a fair judgment, without the browser vendor making a
decision on behalf of or instead of the relying party.
- Additionally all definitions in this proposal are subject to the
Mozilla CA policy and under full control of Mozilla. No special bindings
to interest groups (such as EV) exists and the Mozilla CA policy is open
to the public for review and is free to be implemented by any CA wishing
to conform to this policy.
Please note, that this proposal doesn't provide any suggestions
concerning the UI, but only provides an underlying framework for CAs and
the browser/mail client as a first strategic step. Any UI implementation
can be build according to this framework however and we suggest its
implementation afterwards.
The proposal is also available as a PDF document at
http://apache-2.startcom.org/moz-pki-proposal.pdf
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Phone: +1.213.341.0390
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
