[wpkops] Fwd: Re: I-D Action: draft-ietf-wpkops-trustmodel-02.txt

[Denis <[e-mail]>]

*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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/wpkops