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

["Horne, Rob" <[e-mail]>]

Hi Iñigo,



Thank you for your responses which have provided excellent clarification. Maybe 3.2.1 needs a reference to the BRs? It's not something to get excited about so I'll leave it up to you whether you agree or not.



Regards, Rob







From: [e-mail] [mailto:[e-mail]]
Sent: 06 June 2014 09:29
To: Horne, Rob; [e-mail]
Subject: RE: [wpkops] I-D Action: draft-ietf-wpkops-trustmodel-02.txt



Hi Rob,



In your email





Iñigo Barreira

Responsable del Área técnica

[e-mail]<mailto:[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.





-----Mensaje original-----
De: wpkops [mailto:[e-mail]] En nombre de Horne, Rob
Enviado el: jueves, 05 de junio de 2014 16:54
Para: [e-mail]<mailto:[e-mail]>
Asunto: Re: [wpkops] I-D Action: draft-ietf-wpkops-trustmodel-02.txt



Hi, I've taken a look at this and have a few comments.



Although the security issues are addressed in section 5, I think it could benefit from a little more detail and clarification in sections 2 and 3.



2.1 Root store provider



Does the audit reporting and updating method described conform to any standard? I've seen auditors follow their own procedures which do not match this description.



IB: The Baseline Requirements developed by the CABF indicates which standards are suitable to be used by the auditors and also indicates a procedure to perform the audit but some auditors prefer to use their own procedure to perform audits which is valid meanwhile they follow what the standard requires.



3.2.1. One root CA cross-certifies another root CA



Is there a defined and agreed way for older CAs to cross certify newer CAs particularly if they're not owned by the same organisation? For example if the criterion for cross certification is less than that required by the root store for the original CA there could be some interesting issues. 3.2.2 refers to adherence to the root store policy so should that also be in 3.2.1?



IB: The Baseline Requirements indicates it in section 8.4 as in general. There´s no clear distinction if they shall be owned by the same organization. About the criterion is up to the root CA that signs the other root CA to define it but once is done it "belongs" to the organization and the same audit rules apply. For the second question is similar, but in this case by contract and it´s also indicated in how to audit delegated functions. Maybe a rewording is needed to clarify it



3.2.5 to 3.2.7



I'd have expected more emphasis on technically constraining third party and subscriber RAs and CAs. For one thing legal contracts may be subject to non-disclosure which could make it difficult to audit properly but if they're not technically constrained that will be what's required.



IB: Will check it again



5.3. Root CA compromise



The last sentence is incomplete ;-)



IB: Yes, you´re right. Sean Mullan told me so. It´s already corrected but not published





A further thought: although potentially contentious should the scope be expanded to include other applications which use https but are not, in the traditional sense, web browsers? I'm thinking in particular of applications that utilise the protocol but don't have or use any form of trusted root store. To my mind this is a much bigger security issue than is covered in the draft as it stands. Of course this gets us into a discussion of how synonymous "web" is with "http/s".



IB: In the introduction is indicated that this trust model is to support the communication between the subscriber and the browser. This thought´s been discussed if the scope should be wider but it was decided to keep it as it is now.





Regards, Rob









-----Original Message-----

From: wpkops [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>

Sent: 29 May 2014 11:11

To: [e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>

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





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]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/wpkops



_______________________________________________

wpkops mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/wpkops