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

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.

-----Original Message-----
From: wpkops-boun...@ietf.org [mailto:wpkops-boun...@ietf.org] On Behalf Of
David Chadwick
Sent: Tuesday, October 15, 2013 11:26 AM
To: b...@digicert.com; 'Bruce Morton'; wpkops@ietf.org
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
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: wpkops-boun...@ietf.org [mailto:wpkops-boun...@ietf.org] On
Behalf Of David Chadwick
Sent: Monday, October 14, 2013 5:52 AM
To: Bruce Morton; wpkops WG (wpkops@ietf.org) (wpkops@ietf.org)
Subject: Re: [wpkops] FW: New Version Notification for
draft-barreira-trustmodel-00.txt

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:
The Trust Model draft has been updated.

Bruce.

-----Original Message-----
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
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

_______________________________________________
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops

_______________________________________________
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops



_______________________________________________
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops

_______________________________________________
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops

_______________________________________________
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops

Reply via email to