Subject: [wpkops] FW: New Version Notification for draft-barreira-trustmodel-00.txt

From: Bruce Morton <[email-masked]>
Date: Fri, 11 Oct 2013 12:02:50 +0000

The Trust Model draft has been updated.

Bruce.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 09, 2013 8:47 AM
To: Inigo Barreira; Bruce Morton
Subject: New Version Notification for draft-barreira-trustmodel-00.txt

A new version of I-D, draft-barreira-trustmodel-00.txt has been successfully submitted by Inigo Barreira and posted to the IETF repository.

Filename:	 draft-barreira-trustmodel
Revision:	 00
Title:		 Trust models of the Web PKI
Creation date:	 2013-10-09
Group:		 Individual Submission
Number of pages: 9
URL:             http://www.ietf.org/internet-drafts/draft-barreira-trustmodel-00.txt
Status:          http://datatracker.ietf.org/doc/draft-barreira-trustmodel
Htmlized:        http://tools.ietf.org/html/draft-barreira-trustmodel-00

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.

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.

The IETF Secretariat

---

From: David Chadwick <[email-masked]>
Date: Mon, 14 Oct 2013 12:52:16 +0100

Hi  Bruce

here are my comments on this version

1. There is a potential problem with the scope/Introduction of the 
document, since it only covers trust between the browser and the 
subscriber, when what really matters is trust between the RP and the 
subscriber. How is this gap to be covered?

2. Section 2.1. 3rd para insert may -> The root store provide "may" 
require the root CA....
Rationale. If the root store provider can verify a CA simply because it 
has been accepted by another root store provider, as per the second 
paragraph, then conversely, it may not require it to be annually audited 
but may remove it only when the other root store provider removes it.

3. Section 2.3 insert may -> The subscriber may identify...
Rationale. This more accurately reflects the current situation today, 
doesn't it?

4. Section 3.2.3. A third party RA is not identified in a CA certificate 
as anything, is it?. Remove "as an issuing CA" as this implies it is 
identified as something else.

5. What is the relevance of section 3.3.1? If a third party is 
subcontracted to a party to do work on its behalf, then the party is 
ultimately responsible for this and there is no need to mention it.

6. Section 5.2. Non-unique names. It is unclear whether non-unique names 
refers to Internet wide unique names, or only to CA wide unique names. 
Be explicit.

regards

David

On 11/10/2013 13:02, Bruce Morton wrote:
> _______________________________________________
> wpkops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wpkops
>

---

From: "Ben Wilson" <[email-masked]>
Date: Tue, 15 Oct 2013 11:06:10 -0600

Concerning " 3.3.1.  Subscriber uses agent", David Chadwick wrote, "5. What
is the relevance of section 3.3.1? If a third party is subcontracted to a
party to do work on its behalf, then the party is ultimately responsible for
this and there is no need to mention it."

David,

I think it is helpful to mention or flag where certain relationships might
exist that are not apparent by looking at just the technical/operational
aspects to provide context to model.  Since we are trying to explain how
things operate, I think we need to go slightly beyond just the traditional
three-party model.  

I don't think that the distinguishing feature here is legal.  For instance,
can we say with certainty that one party or another is "ultimately
responsible"?  That might involve legal wrangling and it might ultimately
take a judge to make the determinations of who was responsible for what.
The devil is in the details of the subcontract.  I'm not saying we need to
get into all of that legal stuff - quite the contrary.  

Ben

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Chadwick
Sent: Monday, October 14, 2013 5:52 AM
To: Bruce Morton; wpkops WG ([email-masked]) ([email-masked])
Subject: Re: [wpkops] FW: New Version Notification for
draft-barreira-trustmodel-00.txt

Hi  Bruce

1. There is a potential problem with the scope/Introduction of the document,
since it only covers trust between the browser and the subscriber, when what
really matters is trust between the RP and the subscriber. How is this gap
to be covered?

2. Section 2.1. 3rd para insert may -> The root store provide "may" 
require the root CA....
Rationale. If the root store provider can verify a CA simply because it has
been accepted by another root store provider, as per the second paragraph,
then conversely, it may not require it to be annually audited but may remove
it only when the other root store provider removes it.

4. Section 3.2.3. A third party RA is not identified in a CA certificate as
anything, is it?. Remove "as an issuing CA" as this implies it is identified
as something else.

5. What is the relevance of section 3.3.1? If a third party is subcontracted
to a party to do work on its behalf, then the party is ultimately
responsible for this and there is no need to mention it.

regards

David

On 11/10/2013 13:02, Bruce Morton wrote:
> A new version of I-D, draft-barreira-trustmodel-00.txt has been
successfully submitted by Inigo Barreira and posted to the IETF repository.
> URL:
http://www.ietf.org/internet-drafts/draft-barreira-trustmodel-00.txt
> 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.

---

From: David Chadwick <[email-masked]>
Date: Tue, 15 Oct 2013 18:25:37 +0100

In this case where do you draw the line of who to include and not to 
include. Supply chains are massively long and complex these days. So if 
the mainframe running the OCSP server crashes due to a fault of the 
manufacturer, so that no-one is able to check the revocation status of 
certs, is the computer manufacturer responsible rather than the CA? 
Should we mention this in the spec? Where do you draw the line?

regards

David

---

From: "Ben Wilson" <[email-masked]>
Date: Tue, 15 Oct 2013 11:55:57 -0600

I think the line is determined by balancing factors such as tone, scope,
complexity, detail, etc.  Since this is the first step, I think that section
3.3.1 strikes a proper balance on introducing this concept, at this point in
the project.  I don't think we need to go into more detail about a
particular infrastructure unless a certain use case is prevalent and
relevant.  We could, however, add a little more description about who is the
subscriber, why the subscriber might be relevant to the trust model, to
cover the gap you mentioned between RP and subscriber, etc. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Chadwick
Sent: Tuesday, October 15, 2013 11:26 AM
To: [email-masked]; 'Bruce Morton'; [email-masked]
Subject: Re: [wpkops] FW: New Version Notification for
draft-barreira-trustmodel-00.txt

In this case where do you draw the line of who to include and not to
include. Supply chains are massively long and complex these days. So if the
mainframe running the OCSP server crashes due to a fault of the
manufacturer, so that no-one is able to check the revocation status of
certs, is the computer manufacturer responsible rather than the CA? 
Should we mention this in the spec? Where do you draw the line?

regards

David

On 15/10/2013 18:06, Ben Wilson wrote:
> Concerning " 3.3.1.  Subscriber uses agent", David Chadwick wrote, "5. 
> What is the relevance of section 3.3.1? If a third party is 
> ultimately responsible for this and there is no need to mention it."
>
> David,
>
> I think it is helpful to mention or flag where certain relationships 
> might exist that are not apparent by looking at just the 
> technical/operational aspects to provide context to model.  Since we 
> are trying to explain how things operate, I think we need to go 
> slightly beyond just the traditional three-party model.
>
> I don't think that the distinguishing feature here is legal.  For 
> instance, can we say with certainty that one party or another is 
> "ultimately responsible"?  That might involve legal wrangling and it 
> might ultimately take a judge to make the determinations of who was
responsible for what.
> The devil is in the details of the subcontract.  I'm not saying we 
> need to get into all of that legal stuff - quite the contrary.
>
> Ben
>
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David Chadwick
> Rationale. If the root store provider can verify a CA simply because 
> it has been accepted by another root store provider, as per the second 
> paragraph, then conversely, it may not require it to be annually 
> audited but may remove it only when the other root store provider removes
it.
> 4. Section 3.2.3. A third party RA is not identified in a CA 
> certificate as anything, is it?. Remove "as an issuing CA" as this 
> implies it is identified as something else.
>
> 6. Section 5.2. Non-unique names. It is unclear whether non-unique 
> names refers to Internet wide unique names, or only to CA wide unique
names.
>> Status:
http://datatracker.ietf.org/doc/draft-barreira-trustmodel

---

From: Tim Moses <[email-masked]>
Date: Tue, 15 Oct 2013 17:57:12 +0000

David - I think this is where we rely on judgment and bear in mind the purpose of this exercise.  We want to spotlight those issues that the developers and operators of the Web PKI can reasonably fix.  To your example, the operators can fix OCSP availability, but not fault-tolerant hardware. All the best. Tim.

> On Oct 15, 2013, at 1:26 PM, "David Chadwick" <[email-masked]> wrote:
> 
> In this case where do you draw the line of who to include and not to include. Supply chains are massively long and complex these days. So if the mainframe running the OCSP server crashes due to a fault of the manufacturer, so that no-one is able to check the revocation status of certs, is the computer manufacturer responsible rather than the CA? Should we mention this in the spec? Where do you draw the line?
> 
> regards
> 
> David
>

---

From: David Chadwick <[email-masked]>
Date: Tue, 15 Oct 2013 19:08:25 +0100

What about a CA running an outsourced OCSP service (say in the cloud)? 
Or an outsourced LDAP service for CRLs. Should these be mentioned?

the model starts to get much more complex when we start to consider 
these sorts of third party relationships

regards

David

---

From: Tim Moses <[email-masked]>
Date: Tue, 15 Oct 2013 18:23:39 +0000

---

From: "Ben Wilson" <[email-masked]>
Date: Tue, 15 Oct 2013 12:46:48 -0600

Probably - those are both good suggestions 

-----Original Message-----
From: David Chadwick [mailto:[email-masked]] 
Sent: Tuesday, October 15, 2013 12:08 PM
To: [email-masked]; 'Bruce Morton'; [email-masked]
Subject: Re: [wpkops] FW: New Version Notification for

the model starts to get much more complex when we start to consider these
sorts of third party relationships

regards

David

On 15/10/2013 18:55, Ben Wilson wrote:
> I think the line is determined by balancing factors such as tone, 
> scope, complexity, detail, etc.  Since this is the first step, I think 
> that section
> 3.3.1 strikes a proper balance on introducing this concept, at this 
> point in the project.  I don't think we need to go into more detail 
> about a particular infrastructure unless a certain use case is 
> prevalent and relevant.  We could, however, add a little more 
> description about who is the subscriber, why the subscriber might be 
> relevant to the trust model, to cover the gap you mentioned between RP and
subscriber, etc.
> include. Supply chains are massively long and complex these days. So 
> if the mainframe running the OCSP server crashes due to a fault of the 
>> it has been accepted by another root store provider, as per the 
>> second paragraph, then conversely, it may not require it to be 
>> annually audited but may remove it only when the other root store 
>> provider removes
> it.
>>

---

From: Bruce Morton <[email-masked]>
Date: Tue, 15 Oct 2013 20:15:16 +0000

Hi David,

I have provided some responses to your comments below.

Thank you for your input.

All the best, Bruce.

-----Original Message-----
From: David Chadwick [mailto:[email-masked]] 
Sent: Monday, October 14, 2013 7:52 AM
To: Bruce Morton; wpkops WG ([email-masked]) ([email-masked])
Subject: Re: [wpkops] FW: New Version Notification for draft-barreira-trustmodel-00.txt

Hi  Bruce

1. There is a potential problem with the scope/Introduction of the document, since it only covers trust between the browser and the subscriber, when what really matters is trust between the RP and the subscriber. How is this gap to be covered?
[Bruce Morton] - I tend to agree with you, but we were reminded that the Charter states " authenticity of communications between Web browsers and Web content servers." As such we removed references to relying parties.

2. Section 2.1. 3rd para insert may -> The root store provide "may" 
require the root CA....
Rationale. If the root store provider can verify a CA simply because it has been accepted by another root store provider, as per the second paragraph, then conversely, it may not require it to be annually audited but may remove it only when the other root store provider removes it.
[Bruce Morton] - Agreed.

3. Section 2.3 insert may -> The subscriber may identify...
Rationale. This more accurately reflects the current situation today, doesn't it?
[Bruce Morton] I am not sure "may" applies. The Trust Model is assuming that the Subscriber has a Web server with a domain name. can you give an example?

4. Section 3.2.3. A third party RA is not identified in a CA certificate as anything, is it?. Remove "as an issuing CA" as this implies it is identified as something else.
[Bruce Morton] I have no issue with making this change.

5. What is the relevance of section 3.3.1? If a third party is subcontracted to a party to do work on its behalf, then the party is ultimately responsible for this and there is no need to mention it.
[Bruce Morton] The purpose of mentioning this is the basic trust model suggests that Subscriber manages their own Web server and certificates. The EV guidelines and the Baseline Requirements allow an authorized agent to represent the Subscriber. In some cases the authorized agent might represent many Subscribers. 

6. Section 5.2. Non-unique names. It is unclear whether non-unique names refers to Internet wide unique names, or only to CA wide unique names. 
Be explicit.
[Bruce Morton] We consider a fully qualified domain name to be unique as the domain root is registered. We consider names that cannot be registered as non-unique as many Subscribers could use the same name. So would it be sufficient to state "Internet non-unique name"?

regards

David

---

From: Tim Moses <[email-masked]>
Date: Wed, 16 Oct 2013 15:11:27 +0000

Colleagues - I propose that this version be adopted as the first working group draft.  If you have comments relating to this proposal, please provide them by end-of-day (Friday) 18 Oct.  If accepted, the document can be restyled and submitted ahead of the deadline for submissions for the Vancouver meeting.

Thanks a lot.  All the best.  Tim.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bruce Morton
Sent: Friday, October 11, 2013 8:03 AM
To: wpkops WG ([email-masked]) ([email-masked])
Subject: [wpkops] FW: New Version Notification for draft-barreira-trustmodel-00.txt

Bruce.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 09, 2013 8:47 AM
To: Inigo Barreira; Bruce Morton
Subject: New Version Notification for draft-barreira-trustmodel-00.txt

Abstract:

The IETF Secretariat

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Oct 2013 13:35:32 -0400

Attached is a PDF of the doc, with a large number of suggested edits, 
and some notes.

There were numerous presentation problems, especially missing or 
problematic definitions.

Steve