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

[[e-mail]]

Hi all,

 

I´ve uploaded a new version including some of the suggestions and discarding some others. Please, review.

 

Ben, please check if the cryptolibraries is what you expected. Still don´t see it but if you think it may help for your document, I´m ok.

 

Rob, I reworded the 3.2.1, 3.2.2, 3.25, 3.2.6 and 3.2.7 sections trying to clarify. 

 

Dennis, I´ve included some of your suggestions and was thinking on including the table and the different types of root store providers. For the table, in fact, I did it, but there are more browsers (most of them using the Microsoft root store) than those indicated by you and thought it was not fair to exclude them, and if including the list/table can be big enough and hard to maintain. And regarding the root store provider, well, I agree that in a organization you can manage your roots or even as an end user you can do it, but don´t seem to me that they are "providers" (albeit you changed with managers) so didn´t include them, but I´m open to discuss it. What I did is to include the potential problem when dealing with root certificates and having an issue due to an automatic update.

 

So, feel free to provide any comment.

 

Regards

 

PS: Sorry for the delay

 

 

Iñigo Barreira
Responsable del Área técnica
[e-mail]

945067705

 

 

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

 

De: wpkops [mailto:[e-mail]] En nombre de Denis
Enviado el: lunes, 09 de junio de 2014 18:03
Para: [e-mail]
Asunto: [wpkops] Fwd: Re: I-D Action: draft-ietf-wpkops-trustmodel-02.txt

 

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 models", 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 models"
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 called 2.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. Section 3.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. Section 5 "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