*Comments on draft-ietf-wpkops-trustmodel-02*
* *
*1.** Change :*
* *
* Root CA - a CA with a self signed certificate and whose public key*
* is included as a trust anchor in a root store.*
*into:*
* Root CA - a CA with a self signed certificate and whose public key*
* is included as a trust anchor in a root_certificates_ store.*
* *
* *
*2.** Change :*
* Root store - a set of root certificates which can be trusted by a*
* browser.*
*into:*
* Root_certificates_ store - a set of root certificates which
can be trusted by_the operating system and/or_a browser.*
* *
*3.** Change :*
* Root store policy - the governance policy provided by the root*
* store provider.*
*into:*
* Root_certificates_ store policy - the governance policy that is
applicable to the Root_certificates_ store.*
* *
* *
*4.** Change "Root store provider" into Root store_manager_". If the user
prevents updates to the root certificate store,
then he becomes the root store manager. The computer department of a
organisation to which an employee belongs to
may also be a root store manager.*
* *
* *
*5.** The current draft only describes multiples variations around what is called in
this draft "a basic Web PKI trust model".
However it omits to present an overview of trust models and hence the
limitations of the current trust model are well hidden.
If web browser providers are going to read this RFC it would be beneficial to
provide more information so that the next generation
of web browsers will meet the user needs, which is not the case today.*
* *
*It is thus proposed :*
* *
*(a) to have a section 2 called "2.Trust model_s_", and*
*(b) to change section 2 into section 3 and rename it: "3. Basic Web PKI trust
model".*
* *
* *
*6.** Text proposal for a new section 2 called "2.Trust model_s_"*
* *
*The trust model of current web browsers is well suited to be used with
inexperience users from home or while travelling.
However, it is not really suited to be used for business purposes. When used by
business people, there needs to be
a clear separation between business activities and personal activities: trust
conditions that apply to business web sites
are not the same than those that apply to web sites accessed for personal use.*
* *
*At a coarse level of granularity, there should be at least two different root
certificates stores: one for business use
and one for personal use.*
* *
*At a finer level of granularity, there may be different contexts for business
use as well as for personal use.
As a consequence, more than two root certificates stores may be needed in
practice.*
* *
*Since current browsers are using one and only one certificate store, the only
current way to circumvent the problem is to use
different web browsers, each one using a different root certificates store.
However, this is not sufficient, since by default
every root certificates store is updated either by the Operating System (OS)
provider or by the web browser provider.*
* *
*When a root certificates store is used for business purposes, either the
management of the company or the end user himself
should have the ability to define which root certificates it trusts. As a
consequence, automatic updates from the OS provider
or from the web browser provider must be disabled. Such operation is currently
not really easy to be made, even for experienced users.*
* *
*The next section describes a basic Web PKI trust model which is a model where
a web browser can only use one root certificates store,
which is by default updated by an OS provider or by a web browser provider.*
* *
* *
*7.** Section 2.1 is currently called2.1: "Root store provider"*
* *
*It is proposed to rename it: "2.1 Root store manager". Modified text proposal:*
* *
*A root certificates store manager establishes criteria or requirements for
accepting a given root certificate
in a given root certificates store. A root certificates manager may be:*
- *the provider of an OS,*
- *the provider of a web browser,*
- *the computer department of a organisation,*
- *the end-user himself.*
* *
*The provider of an OS or of a web browser usually determines the root
certificates store policy for the root certificates
placed under his control. It establishes requirements for accepting a root
certificate.*
*These requirements must be met by a candidate root CA in order to be included
in their root certificate store.
In such a case, the root certificates store manager may require the candidate
root CA to be subject to an annual compliance audit
performed by a third party auditor as specified in [BR-certs]. The audit
requirements are defined by the root certificates store manager.
The audit is based on an accepted schema of the standards (e.g., WebTrust or
ETSI). A third party auditor generates an audit report
which is provided to the root store provider. If the audit report states the
root CA did not comply with the auditing standards,
then the root CA will be required to take corrective actions. Once the
corrective actions are completed, then an updated report
is submitted to the root store provider. If the status of the root CA is not
acceptable to the root store provider, then
the root CA certificates may be removed from the root store or the indications
from the browser (e.g., removal of https indicator)
may change for certificates verified under that root CA.*
* *
*The computer department of an organisation may take control of the
workstations of the employees. In such a case, the employees
are no more able to perform management actions, e.g. installing new
applications, and among the many controls performed
by the computer department of the organisation, root certificates stores are
directly managed by the computer department of the organisation.*
* *
*The end-user, if correctly educated, may manage himself the various root
certificates stores that are present on his workstation
by adding root certificates or by deleting root certificates that were
initially present. In such case, any external automatic updates
of these root certificates stores must be disabled.*
* *
* *
*8.** Section3.1.1 "Browser adopts root store" mentions on page 6:*
* *
* The browser will provide its own trust and security indications. The*
* browser may determine whether it will provide extended validation*
* indications. *
* *
*In this document it is the first time that the expression "extended
validation" is being used, but without any explanation.
Please provide more explanations and indicate an external reference.*
* *
* *
*9.** Section5 "Security Considerations" is missing to address one important
security issue.*
* *
*There is a problem with the automatic updates of root certificates: when an
end-user carefully removes root certificates
in a given root certificates store and add others root certificates without
knowing that at the next automatic update
(which will happen at an unknown date) all his efforts will be annihilated.
This will then create a denial of service
(for the root certificates that have been added) and may introduce some
vulnerabilities (for the root certificates that
have been suppressed). Please add a new sub-section and text.*
* *
* *
*10.** The problem with such a draft is that it will not really help the
end-user, since there is no indication of which
root certificates store is being used by each web browser.*
* *
*The following table should be added, with the X replaced by an indicator
stating whether the web browser is using
its own root certificates store or the root certificates store from the
supporting OS.*
* *
* | | IExplorer | Firefox | Opera | Chrome | Safari
|*
* | Windows XP | X | X | X | X | X
|*
* | Windows 7+ | X | X | X | X | X
|*
* | Mac OS X | N/A | X | N/A | X | X
|*
* | Linux | N/A | X | X | X |
N/A |*
* *
Denis
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web PKI OPS Working Group of the IETF.
Title : Trust models of the Web PKI
Authors : Inigo Barreira
Bruce Morton
Filename : draft-ietf-wpkops-trustmodel-02.txt
Pages : 11
Date : 2014-05-29
Abstract:
This is one of a set of documents to define the operation of the Web
PKI. It describes the currently deployed Web PKI trust.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-wpkops-trustmodel/
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-wpkops-trustmodel-02
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-wpkops-trustmodel-02
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
wpkops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/wpkops
_______________________________________________
wpkops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/wpkops
