WPKOPS WG at IETF86 14 March 2013, 13:00 - 15:00 EDT (17:00 - 19:00 UTC) Draft Agenda ============ 1. Administrivia - Chairs (5 minutes) 2. Charter Review - Chairs (10 mins) 3. Trust Model - Bruce Morton (25 mins) 4. Certificate revocation - (Phillip Hallam Baker (25 mins) 5. Field and extension processing for certificates, CRLs and OCSP – Jeremey Rowley (25 mins) 6. TLS stack operation – Adam Langley & Paul Hoffman (25 mins) 7. Wrap up – Chairs (5 mins) Charter: http://datatracker.ietf.org/wg/wpkops/charter/ Chair: Sharon Boeyen Note: All slides are available on the IETF 86 Proceedings page: 1. Administrivia ================ Sharon Boeyen called the meeting to order. This is the first meeting of the WPKOPS WG. There is an opening for co-chair, and if anyone is interested, contact the AD, Joel Jaeggli. Sharon covered the remaining administrivia including minutes, jabber scribes, blue sheets, and the IETF Note Well. 2. Charter Review ================= Sharon Boeyen reviewed the approved working group charter including what was in scope, what was explicitly out of scope, and the planned milestones. 3. Trust Model ============== Bruce Morton provided an overview of the Trust Model draft. When the document was originally created there wasn't a working group so the name isn't properly aligned. It will be changed to reflect its status as a working group document. Bruce described the basic trust model and listed number of variants to that basic model. Terminology immediately became an issue. Steve Kent asked when you would want to have a situation where a "Root CA cross-certifies another root CA". As far as the relying part is concerned it is not a root, it is just another subordinate CA because it has a certificate that is not self-signed. Leif Johansson pointed out that this has happened (AdTrust example), but it isn't sustainable. Paul Hoffman noted that WebPKI doesn't work like the current definitions or the 5280 definitions. Sharon pointed out that terminology and definitions are going to be really tough in this working group. Joel Jaeggli reminded the group that the charter specifically calls this out as an issue. There are existing documents that detail how things should be. This working group is to determine how things actually are. Bruce continued to describe variants or high level exceptions that have been defined thus far. There may be additional ones or some of the existing ones may be combined. In addition, there is a question about whether we are approaching the trust model properly in order to document it. A lengthy discussion on the role of CPSes in the WebPKI followed. Paul Hoffman feels that CPSes are not actually used in the WebPKI. For example, you are in the root pile in the interim when an auditor is confirming you are doing what your CPS says, and you are not taken out of the root pile when you violate your CPS. The WebPKI doesn't know that you are violating your CPS. Yaov Nir commented that you are taken out of the root pile when you get caught. Jeremy pointed out that browsers do use the information from the CPS, and it might be worth evaluating what currently happens for noncompliance. Phillip HallamBaker commented that drawing lessons from Diginotar is a really bad idea. If they weren't thrown out for one reason, they would have been thrown out for another. The only purpose for the CPS is that it is the document against which the auditors validate. Ryan Sleevi noted that he is not aware of a CA that has failed an audit and owned up to it. During a failing audit, they are given a chance for remediation. CPSes do play an important role but there is not a technical way to measure it. Bruce Morton discussed a document strategy that defines the components but doesn't address CPSes. Yaov Nir asked what does an affiliate mean? It is when another company is doing the RA work on behalf of the CA. It doesn't have to be an ownership relationship. Mike Jenkins congratulated the author for doing this work. There is a great deal of stuff here that needs to be broken up. Issuance of certificates is different than usage of certificates. Enterprises interact with certificates in a different way than "grandmas and students. Sharon noted that she and Bruce had discussed this earlier today. IF there is agreement on the high level diagram, it is expected that each bubble in the diagram would be broken out and described. The question is does this picture represent the high level. Stephen Farrell said that it still is not clear what the document is for. While it did lead to good conversation, it is not clear what level of detail this document contain, and thinking about how it might be used might lead to clarity on what to put in. 4. Certificate revocation ========================= Phillip HallamBaker presented on dimensions of the certificate revocation topic. The purpose of the brief is to determine if all the dimensions are covered in the planned effort. Along those lines, Paul Hoffman noted that out-of-band information held by browsers needs to be added. Jeremy noted that in 2560bis (in last call) a CA can report revoked or good for a certificate that never existed. The point remains that with CRLs you don't know if the certificate ever existed. Sharon asked if he was going to document what the OCSP signing certificates look like, and PHB indicated that we should probably do that. The question of what is in scope was raised again. Sharon reminded the group that only what is actually being done today is within scope. PHB would like to know what happens when legacy applications encounter new extensions. Paul Hoffman wondered if it is possible to do, but no one did it, is it still within scope? Steve Kent feels that if it is possible to do it because of browser implementations, it should be documented in this working group. Adam Langley agreed that all this should be documented, but he wondered how the information was going to be gathered - experimentation, surveys, or other mechanisms. PHB plans to write a matrix with the possibilities, ask the browsers to self-report, and possibly evaluate some products. PHB wrapped up the presentation by asking what he has missed thus far. Some of the items from the floor included caching behavior in clients and OCSP stapling behavior. Stephen Farrell asked if he was going to cover how do I tell a CA to revoke a key. PHB wondered if the criteria for issuing a certificate is out of scope does that mean the criteria for revoking it is also out of scope. How the revocation is reported should be in scope, but the criteria for the revocation is out of scope. A final question of scope is how much historical behavior should be documented. If there is still a small amount of it out there, it should be included. 5. Field and extension processing for certificates, CRLs and OCSP =========================================================== Jeremy Rowley presented on the plan for documenting field and extension processing. There were several questions related to the scale of the effort. The user agent and operating system variants shown on the slide is a starting point that may be modified. Stephen Farrell pointed out that if you multiply all the variations, he gets 54,000. He wonders how you make use of all that data. Is this going to be kept up to date over time? Sharon again reminded the group that we are documenting what actually exists. Joel pointed out the fact that the charter has given the working group the power to arbitrarily limit the scope. If it is sufficiently rare, you can leave it out. The hope is that having the document available will encourage harmonization of behaviors. There was a discussion on how the data will be gathered. The current plan is to crowd source the data using a shared spreadsheet (finishing in three months). Adam Langley expressed a concern that self reporting is not going to work and may lead to inaccurate data. We may actually need a test suite to collect data. There are some ongoing efforts that might be leveraged, and volunteers are welcome to contribute. However, there is some evidence that test harnesses provide different results than the browsers. Sharon mentioned a NIST PKIX test suite looking at whether or not a relying party processes information properly. The real objective is to get a test suite going. 6. TLS stack operation ====================== Paul Hoffman and Adam Langley presented a discussion on scoping the document on TLS stack operation. The slides covered what is in scope (Comon PKIX issues for the TLS stack) and what is still under discussion for inclusion (Less common PKIX issues for the TLS stack). Adam would really like to document several TLS protocol tweaks that common SSL libraries use in order to achieve interoperability. There are also several UI related things around alerts, indicators, and preferences especially as related to configuration. All of this is currently considered in scope for this document. 7. Wrap up – Chairs =================== With the conclusion of the planned agenda, Sharon opened the floor for open mic. Paul Hoffman asked if firewalls that act as web browsers are in scope. Yaov Nir thinks proxies such as firewalls are trying to be as transparent as possible and are out of scope. Adam Langley thinks that they are in scope because they represent a significant portion of users. Melinda Shore feels they are a different architectural element bringing another level of complexity and are therefore not in scope. They represent things that users don't see. Yaov Nir upon reconsideration think that maybe we should consider proxies within the scope. Stephen wondered whether TLS accelerators were in scope. Perhaps it is not that the boxes as an element are in scope, but their impact on behavior is in scope. Paul Hoffman asked to continue the discussion on the mailing list. Sharon adjourned the meeting at 14:42 EDT.