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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to